解説

OAuth 2.0はリソースへのアクセス権限を第三者アプリケーションに委譲するための認可フレームワーク（RFC 6749）。登場人物は4者：①リソースオーナー（利用者A）②クライアント（WebサービスD）③認可サーバ（この問題ではWebサービスCが兼任）④リソースサーバ（WebサービスC）。Authorization Code Flowの流れ：利用者AがWebサービスDを使おうとする→WebサービスDがWebサービスC（認可サーバ）に認可要求を送る→利用者Aが認可画面で同意する→認可サーバが認可コードをWebサービスDに渡す→WebサービスDが認可コードをアクセストークンに交換する→WebサービスDがアクセストークンでリソースBにアクセスする。アクセストークンを発行するのは認可サーバ（WebサービスC）であることが重要。OAuth 2.0はあくまで「認可」のフレームワークで、認証（本人確認）はOIDC（OpenID Connect）が担う。

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

選択肢 イ

WebサービスCがWebサービスDにデジタル証明書を送信するというのはOAuth 2.0のプロトコルフローに存在しない操作。OAuth 2.0はデジタル証明書ではなくアクセストークン（通常はJWT形式のベアラートークン）を使って権限委譲を実現する。TLSハンドシェイクでサーバ証明書の交換は行われるが、それはOAuth 2.0のプロトコルとは別の話。

選択肢 ウ

アクセストークンを発行するのはクライアント（WebサービスD）ではなく、認可サーバ（WebサービスCが兼任）。OAuth 2.0においてWebサービスDはアクセストークンを受け取って使う「クライアント」の役割であり、トークンを生成・発行する権限を持たない。トークン発行は認可サーバの専権事項で、利用者の同意確認後に認可サーバが発行する。

選択肢 エ

WebサービスDが利用者Aのデジタル証明書をWebサービスCに送信するのはOAuth 2.0のフローには存在しない操作。OAuth 2.0では利用者の代わりにクライアントアプリケーション（WebサービスD）が動作し、利用者のデジタル証明書を転送するプロセスはない。クライアント認証にクライアント証明書を使う場合はあるが、利用者証明書を転送するのではない。

解くときのポイント

OAuth 2.0のロール: リソースオーナー（利用者A）・クライアント（WebサービスD）・認可サーバ・リソースサーバ（WebサービスC）。認可コードフロー（Authorization Code Flow）の手順を理解する。