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

OAuth2.0の認可機構【午前2解説】

正解の理由

解法ステップ

1. 「認可」と「認証」の違いを明確にする
   • 認可（authorization）：誰がどのリソースにどの範囲でアクセスできるかを決める。
   • 認証（authentication）：アクセスしてきた者が本人であるかを確認する。
2. 文中の主体（認可サーバ／認証サーバ）と動詞（確認する／許可を得て権限を付与する）を照合する。
3. OAuth 2.0 の目的は「クライアントに権限を付与するための仕組み」である点を基準に正誤を判定する。
4. 例外（ROPC）や関連仕様（OpenID Connect）について短く注意する。

選択肢別の誤答解説

• ア: 「認可を行うためのプロトコルであり、認可サーバが…本人であるかどうかを確認するためのもの」
  誤り。OAuth 2.0 は認可が目的であり、認可サーバはリソースオーナーからの同意を得てトークンを発行します。認可サーバは認証（本人確認）を行うことが多いものの、OAuth 自体は「本人確認」を主目的とするプロトコルではありません（本人確認が必要な場面では認証処理を組み合わせます）。
• ウ: 「認証を行うためのプロトコルであり、認証サーバが…本人であるかどうかを確認するためのもの」
  誤り。これは認証プロトコルの説明であり、OAuth 2.0 の定義とは合致しません。認証を目的とする場合は OpenID Connect のような上位仕様を用います。
• エ: 「認証を行うためのプロトコルであり、認証サーバが、利用者の許可を得てサービスに対し権限を付与するためのもの」
  誤り。説明が認証と認可を混同しており不適切です。認証サーバは本人確認が目的であり、「利用者の許可を得てサービスに権限を付与する」役割は認可の説明です。

よくある誤解

• OAuth 2.0 は「ログイン（本人確認）」のための仕組みである：誤り。OAuth は認可が目的で、ログイン機能が欲しい場合は OpenID Connect を使うのが正しい選択です。
• クライアントが常に利用者のパスワードを扱わない：原則としてそうですが、ROPC グラントのように仕様上例示されている例外が存在します。セキュリティ上は避けるべきです。
• アクセストークンは同じ意味でどこでも使える認証情報：誤り。アクセストークンはリソースサーバごとにスコープや寿命が設定され、取り扱いに注意が必要です。

補足コラム

• 代表的なグラントタイプ（簡単に）
  • Authorization Code：一般的で安全なブラウザ／サーバ型フロー。認可コードを交換してアクセストークンを取得。
  • Implicit（非推奨）：単一ページアプリ向けに設計されたがセキュリティ上の問題から推奨されない。
  • Client Credentials：サーバ間でクライアント自身の権限でアクセスする際に使用。
  • Resource Owner Password Credentials（ROPC）：利用者のユーザ名・パスワードを直接クライアントが扱う方式。仕様上存在するが非推奨で、使用は極力避けるべき。
• OpenID Connect（OIDC）は OAuth 2.0 を拡張して「認証」を提供する仕様で、ログインや ID トークンの発行を扱います。
• 実務上の注意点：トークンの保護、スコープの最小化、リフレッシュトークンの運用、暗号化・TLS必須などを徹底すること。

FAQ