情報処理安全確保支援士 2017年 春期 午前2 問14

アクセストークン発行主体【午前2解説】

正解の理由

解法ステップ

1. OAuth2の主要な役割を確認する（リソースオーナー、クライアント、認可サーバー、リソースサーバー）。
2. アクセストークンの発行主体はどの役割かを知る（認可サーバーが発行、リソースサーバーは検証・提供）。
3. 選択肢と照合する：WebサービスAが認可サーバーを兼ねると解釈できれば ア が一致する。他はOAuth2の基本流れと一致しない。
4. ディジタル証明書を送る選択肢はOAuth2の標準フローではない点を排除する。

選択肢別の誤答解説

• ア（正答）: 認可サーバーがアクセストークンを発行するというOAuth2の基本原則に合致します。WebサービスAが認可サーバーの役割を兼ねる場合、Aがトークンを発行します。
• イ: 利用者のディジタル証明書をWebサービスBに送信する、はOAuth2の標準的な手順ではありません。ディジタル証明書はTLSやクライアント認証（mTLS）で使われることはありますが、OAuth2のアクセス付与の主流ではありません。
• ウ: WebサービスB（クライアント）がアクセストークンを発行する、は誤りです。クライアントは認可サーバーからトークンを取得する立場であり、自己発行することはできません（例外的に独自実装は可能でもOAuth2仕様では認可サーバー発行が原則です）。
• エ: WebサービスBが利用者のディジタル証明書をWebサービスAに送る、もOAuth2の典型フローではないため誤りです。証明書の送信は認可付与やトークン発行の代替手段ではありません。

よくある誤解

• 誤解1: 「リソースサーバーが常にアクセストークンを発行する」
  実際はアクセストークンは認可サーバーが発行し、リソースサーバーは通常トークンを検証する側です。両者を同一プロダクトが兼ねる場合のみ、そのプロダクトが発行することになります。
• 誤解2: 「OAuth2ではディジタル証明書（公開鍵証明書）が必須」
  標準フローではアクセストークン（ベアラートークンやJWT）を用いるのが一般的で、証明書はmTLSやクライアント認証など特定の拡張で使われます。
• 誤解3: 「JWT＝発行者がリソースサーバー」
  JWTはトークンの形式であり、署名を検証すれば発行者（issクレーム）を確認できます。発行者は認可サーバーであることが多いです。

補足コラム

1. 利用者がクライアント（WebサービスB）に対してアクセス承認を行うため、認可サーバーに認可要求を送る（ブラウザ経由のリダイレクト）。
2. 認可サーバーは認可コードをクライアントに返す。
3. クライアントは認可コードを認可サーバーのトークンエンドポイントに送り、アクセストークンを取得する。
4. クライアントは取得したアクセストークンを用いてリソースサーバー（WebサービスA）にAPIリクエストを行う。
5. リソースサーバーはトークンの署名検証またはトークンイントロスペクションを行い、正当ならリソースを返す。

• トークンはTLSで保護された通信上で扱う（ベアラートークンは傍受で危険）。
• リソースサーバーはトークンの有効性を認可サーバーに問い合わせる（イントロスペクション）か、公開鍵でJWTを検証する。
• 認可サーバーとリソースサーバーが同一プロダクトの場合、内部APIで検証することが多い。

FAQ