解説

OAuth 2.0はRFC 6749で定義された「認可」のためのフレームワーク（b：正解）。認可サーバ（Authorization Server）が、リソースオーナー（ユーザ）の許可（同意）を得た上で、クライアント（サービス）に対してアクセストークンを発行し、リソースサーバ上のリソースへの適切なアクセス権限を委譲する仕組みである。OAuth 2.0は認可に特化しており、それ自体は認証機能を持たない点が重要。認証機能はOpenID Connect（OIDC）がOAuth 2.0の上位レイヤとして提供する。代表的なユースケース：「Twitterアカウントで別サービスにログイン」する際にTwitterがアクセストークンを発行して当該サービスに渡し、ユーザ情報へのアクセスを許可するケース。グラントタイプとして認可コードフロー・クライアントクレデンシャルフロー等が定義されている。

なぜ他の選択肢は違うのか

選択肢 ア

「認可サーバがアクセスしてきた者が利用者本人かどうかを確認する」のは認証（Authentication）の説明であり、OAuth 2.0は認可（Authorization）のプロトコルである。認証はOpenID Connectが担い、OAuth 2.0自体はリソースへのアクセス権委譲を目的とし、本人確認機能は持たない。

選択肢 ウ

「認証サーバがアクセスしてきた者が利用者本人かどうかを確認するためのプロトコル」はOpenID ConnectやKerberos等の認証プロトコルの説明。OAuth 2.0は「認可」プロトコルであり、本人確認（認証）ではなく、リソースへのアクセス権限の委譲（認可）が主目的である。

選択肢 エ

「認証サーバがリソースオーナーの許可を得てサービスに権限を付与する認証プロトコル」はOAuth 2.0の動作に一部似ているが、OAuth 2.0は認証プロトコルではなく認可フレームワークである。また認証と認可を混同している点で不正確。正しくは「認可サーバ」が「認可（Authorization）」を行う。

解くときのポイント

OAuth 2.0（認可）とOpenID Connect（認証）の区別が頻出。OAuth 2.0のアクセストークンは「何ができるか（スコープ）」を制御、OpenID ConnectのIDトークンは「誰であるか」を証明する。