Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

title: “OAuth2 / OIDC / 外部 ID 連携のテスト” part: “Part 4” chapter: “4-3”

OAuth2 / OIDC / 外部 ID 連携のテスト

本章では、Part 2 で整理した OAuth2 / OIDC の基礎を前提とし、Pentest におけるテスト観点を整理する。特に、Google などの外部 IdP（Identity Provider / ID プロバイダ）と連携するケースを想定する。

本章のゴール

  • 前提：OAuth2 / OIDC の基本ロールと Authorization Code + PKCE の流れ（Part 2）を説明できる。
  • 到達目標：リダイレクト URI、スコープ、トークン検証、ログアウト／セッション連携などの観点で、実装のリスクを体系的に点検できる。
  • 対応演習：OAuth2 / OIDC を利用している演習環境がある場合、認可フローのトラフィックを Burp Suite で観察し、redirect_uri／スコープ／トークンのクレーム検証に関する挙動を整理する。

テスト対象の整理

OAuth2 / OIDC 関連のテストでは、次の対象を明確にする。

  • クライアントアプリケーション（Web / モバイル / SPA など）
  • 認可サーバ（IdP / Authorization Server）
  • リソースサーバ（保護された API）

また、次の情報を事前に確認しておく。

  • 利用しているフロー（Authorization Code + PKCE、Client Credentials など）
  • クライアント登録情報（クライアント ID、リダイレクト URI、スコープなど）
  • トークンの形式（JWT かどうか、署名アルゴリズム）

図4-3 は、Authorization Code + PKCE を前提に、主要なテスト観点をフロー上に対応付けた概要図である。以降の各観点は、「どのリクエスト／レスポンス」「どのコンポーネント」の問題かを切り分けて整理すると、報告時の説明が明確になる。

図4-3: OAuth2 / OIDC（Authorization Code + PKCE）のフローと主要テスト観点（概要）

sequenceDiagram
    participant U as User Agent (Browser)
    participant C as Client (App)
    participant AS as Authorization Server / IdP
    participant RS as Resource Server (API)

    U->>C: アプリ利用開始
    C->>AS: 認可リクエスト\n(redirect_uri, scope, state,\ncode_challenge, nonce)
    Note right of AS: テスト観点\n- redirect_uri の検証\n- scope の適切性\n- state/nonce の検証
    U->>AS: 認証・同意
    AS-->>C: 認可レスポンス\n(code, state)
    C->>AS: トークンリクエスト\n(code, code_verifier, redirect_uri)
    Note right of AS: テスト観点\n- PKCE 強制\n- code の再利用/置換\n- クライアント分離
    AS-->>C: トークン発行\n(access_token, id_token)
    C->>RS: API リクエスト\n(Authorization: Bearer access_token)
    RS->>RS: トークン検証\n署名/iss/aud/exp 等
    Note right of RS: テスト観点\n- 署名検証\n- iss/aud/exp\n- スコープ/権限\n- ログアウト連携
    RS-->>C: API レスポンス

代表的なテスト観点

OAuth2 / OIDC に関する代表的なテスト観点は以下のとおりである。

  • リダイレクト URI の検証
    • プレ登録された URI 以外を許可していないか
    • オープンリダイレクトと組み合わせて認可コードやトークンが奪取されないか
  • スコープの適切性
    • 不要に広いスコープ（例：メール・プロフィール以外の権限）が常に付与されていないか
    • クライアントごとに必要最小限のスコープに制限されているか
  • トークン検証
    • ID トークン／アクセストークンの署名検証が正しく行われているか
    • iss / aud / exp / iat などのクレームが検証されているか
    • nonce を利用するフローで、リプレイ攻撃防止がなされているか
  • ログアウトとセッション連携
    • ログアウト後もトークンが有効なまま残っていないか
    • ブラウザセッションとトークンのライフサイクルが整合しているか

外部 IdP 連携（例：Google ID）

Google などの外部 IdP と連携する場合、次のようなリスクが考えられる。

  • クライアント側で ID トークンの署名検証を省略している
    • 任意の ID トークンを生成して送信できてしまう
  • メールアドレスなどのクレームを安易に信頼している
    • ドメイン検証が不十分で、想定外のユーザが管理権限を取得しうる
  • アカウント連携時の確認不足
    • 既存アカウントとの紐付け確認が弱く、別人のアカウントと誤って統合される

Pentest では、ブラウザプロキシや JWT デバッグツールを用いて、ID トークンの内容とサーバ側の検証挙動を観察する。可能であれば、テスト用の IdP 設定（テストクライアント、サンドボックス環境）を利用し、本番アカウントに依存しない形で検証する。

攻撃シナリオ例

OAuth2 / OIDC 関連の脆弱性を報告する際は、次のようなシナリオとして整理すると理解されやすい。

  • 攻撃者が特定のリダイレクト URI を悪用し、被害者がログインした際に認可コードを奪取する
  • 攻撃者が独自のクライアントから発行したトークンを、別のクライアント向け API に対して利用できてしまう
  • 攻撃者がメールアドレスのクレームだけを利用してアカウント連携を行い、組織内の管理者アカウントに不正アクセスする

これらのシナリオに対する対策として、リダイレクト URI の厳格な検証、クライアントごとのスコープ分離、トークン検証ロジックの統一（共通ライブラリの利用など）を推奨する。

次に読む章

本章のポイント

  • OAuth2 / OIDC のテストでは、クライアント／認可サーバ／リソースサーバの役割と、採用フロー・トークン形式を先に特定する。
  • リダイレクト URI、スコープ、トークン検証（署名、iss / aud / exp / nonce など）、ログアウトとセッション連携を主要な検証観点として整理する。
  • 外部 IdP 連携では「クレームの過信」「署名検証の省略」「アカウント連携の確認不足」が典型リスクであり、攻撃シナリオとして報告すると伝達性が高い。