概要

OAuth 2.0 は「認可（Authorization）」のフレームワークです。サードパーティアプリケーションが、ユーザの代わりにリソースサーバのAPIにアクセスする権限を安全に委譲する仕組みを定義します。OIDC（OpenID Connect） は OAuth 2.0 の上に「認証（Authentication）」レイヤーを追加した拡張仕様です。

仕組みと動作原理

登場人物

ロール説明
リソースオーナーユーザ本人
クライアントAPIにアクセスするアプリケーション
認可サーバアクセストークンを発行するサーバ（例: Google, GitHub）
リソースサーバ保護されたAPIを公開するサーバ

認可コードフロー（最も安全・推奨）

ユーザ → クライアント：「ログイン」ボタン押下
クライアント → 認可サーバ：認可リクエスト（response_type=code）
認可サーバ → ユーザ：ログイン＆同意画面
ユーザ → 認可サーバ：同意
認可サーバ → クライアント：認可コード（短命・1回使い切り）
クライアント → 認可サーバ：認可コード＋クライアントシークレットでトークンリクエスト
認可サーバ → クライアント：アクセストークン（＋IDトークン・リフレッシュトークン）
クライアント → リソースサーバ：アクセストークン付きAPIリクエスト

PKCE（Proof Key for Code Exchange）

モバイルアプリや SPA などクライアントシークレットを安全に保管できない環境向けの拡張。

  1. クライアントがランダムな code_verifier を生成
  2. SHA-256 で code_challenge = BASE64URL(SHA256(code_verifier)) を計算
  3. 認可リクエストに code_challenge を含める
  4. トークンリクエスト時に code_verifier を送信（認可サーバで検証）

OAuth 2.0 と OIDC の違い

OAuth 2.0OIDC
目的認可（APIアクセス権限の委譲）認証（ユーザが誰かを確認）
主なトークンアクセストークンIDトークン（JWT形式）
ユーザ情報の取得スコープ依存（標準外）UserInfo エンドポイントで標準化

IDトークン（JWT）の構造

ヘッダ.ペイロード.署名

ペイロードの主要クレーム：

  • sub：ユーザの一意識別子
  • iss：発行者（認可サーバ）
  • aud：受取先（クライアントID）
  • exp：有効期限
  • iat：発行日時

SC試験での頻出ポイント

  • OAuth 2.0 は「認可」、OIDC は「認証」：混同させる選択肢が頻出
  • 認可コードフローを使う理由：アクセストークンをブラウザのURL（フラグメント）に露出させないため
  • PKCE の目的：認可コードの横取り攻撃（Authorization Code Interception Attack）を防ぐ
  • リフレッシュトークン：アクセストークンの有効期限が切れた際に新トークンを取得するための長命トークン
  • スコープ：クライアントが要求するリソースのアクセス範囲（例: read:email）

よくある誤問・ひっかけパターン

誤り① 「OAuth 2.0 でユーザのパスワードが認可サーバに渡される」→ 誤。パスワードはリソースオーナーパスワードクレデンシャルフロー（非推奨）以外では渡りません。

誤り② 「IDトークンをAPIアクセスに使用する」→ 誤。IDトークンはクライアントがユーザを認証するためのもの。API アクセスにはアクセストークンを使います。

誤り③ 「PKCE はサーバサイドアプリには不要」→ 現在の推奨はすべてのクライアントタイプで PKCE を使用（RFC 9700）。

関連用語

重要キーワード

用語説明
アクセストークンAPIアクセスを許可するトークン。短命（数時間〜数日）
IDトークンOIDCで発行されるJWT。ユーザの認証情報を含む
認可コードトークン取得のための短命な中間コード（1回使い切り）
PKCEクライアントシークレット不要でコード横取り攻撃を防ぐ拡張
スコープクライアントが要求するアクセス権限の範囲
リフレッシュトークンアクセストークン再発行に使う長命トークン