OAuth 2.0 が解決するために設計された本来の目的として、最も適切なものはどれですか？

解説

正解は「ユーザーのパスワードを渡さずに」で始まる選択肢です。OAuth 2.0 は認可（Authorization：何をしてよいかの許可）の委譲のための仕組みで、ユーザーは自分のパスワードを第三者アプリに教えることなく、必要な範囲だけのアクセス権を与えられます。パスワードの代わりにアクセストークンを渡す流れたとえば写真印刷アプリが、ユーザーのクラウドストレージ上の写真を読み取りたい場面を考えます。OAuth 2.0 では次のように進みます。アプリ（クライアント）がユーザーを認可サーバー（許可を出すサーバー）へリダイレクトするユーザーは認可サーバー上でログインし、「写真の読み取り」だけを許可するアプリはアクセストークン（期限付きの許可証）を受け取り、それを付けて API を呼び出すトークンには scope（許可範囲）と有効期限があるため、パスワードを丸ごと渡す場合と違って、アプリに与える権限を絞れ、不要になれば取り消すこともできます。アクセストークンを「ログインの証明」に使うと危ない理由「ユーザーが誰であるかを証明し」は、OAuth 2.0 の目的としてとくに誤解されやすい内容です。OAuth 2.0 の仕様が定めるのはアクセス権の委譲であり、アクセストークンは「誰がこのアプリにログインしたか」を示す証明書ではありません。トークンを受け取れたことだけでログイン成功とみなす実装は、別のアプリ向けに発行されたトークンを持ち込まれる攻撃などに弱くなります。認証（Authentication：本人確認）が目的なら、OAuth 2.0 の上に本人情報の仕組みを載せた OpenID Connect を使い、発行される ID トークンを検証します。そのほかの選択肢が誤りである理由「通信経路を暗号化して」は TLS（HTTPS）の役割です。OAuth 2.0 は TLS の利用を前提としていますが、暗号化そのものは担いません。「サーバー間で共有鍵を使い」は HMAC 署名などによる API 認証方式の説明です。旧仕様の OAuth 1.0 はリクエスト署名を用いていましたが、それも委譲を安全に行うための手段であり、目的ではありません。参考RFC 6749: The OAuth 2.0 Authorization FrameworkOpenID Connect Core 1.0