title: “JWT / OAuth2 / OIDC の基礎” part: “Part 2” chapter: “2-3”

JWT / OAuth2 / OIDC の基礎

本章では、API および認証・認可の文脈で頻出する JWT（JSON Web Token）、OAuth2、OpenID Connect（OIDC）の基礎を整理する。詳細な攻撃手法やテスト観点は Part 4 で扱うため、ここでは構造と役割に焦点を当てる。

本章のゴール

• 前提：HTTP ヘッダと Cookie の基礎、およびセッション管理の概要（前章）を把握している。
• 到達目標：JWT の構造と検証観点、OAuth2 のロールと Authorization Code + PKCE の流れ、OIDC の ID トークンと主要クレームを説明できる。
• 対応演習：Burp Suite で Authorization ヘッダ等のトークンを観察し、JWT のヘッダ／ペイロードを読み解く。

JWT の構造

JWT は、JSON 形式のクレームセットに署名（または暗号化）を施し、コンパクトなトークンとして表現する仕組みである。典型的な形式は次のとおり。

header.payload.signature

• Header
  アルゴリズム（alg）やトークン種別（typ）など、メタ情報を含む。
• Payload
  sub（主体）、iss（発行者）、exp（有効期限）などのクレームを含む。アプリケーション固有のクレームを含めることも多い。
• Signature
  Header と Payload を結合し、秘密鍵や共有鍵を用いて署名した値。

Pentest の観点では、次の点が典型的な確認ポイントとなる。

• 署名アルゴリズムが適切か（none アルゴリズムの許容有無など）
• 秘密鍵・共有鍵の管理が適切か（推測可能な値を用いていないか）
• 有効期限（exp）や発行時刻（iat）が適切に設定・検証されているか
• クレームの整合性（iss、aud など）が検証されているか

これらの詳細な攻撃パターンは、Part 4 にて API 特有の文脈と合わせて解説する。

OAuth2 のロールとフロー

OAuth2 は「認可」のフレームワークであり、一般的に以下のロールが登場する。

• リソースオーナー（Resource Owner）
  データの所有者（多くの場合、エンドユーザ）。
• クライアント（Client）
  リソースオーナーに代わって API にアクセスするアプリケーション。
• 認可サーバ（Authorization Server）
  エンドユーザの認証と、アクセストークンの発行を担当する。
• リソースサーバ（Resource Server）
  保護されたリソースを提供する API。

これらのロールの関係を、簡単に言い換えると次のようになる。

• ユーザは、クライアント（アプリケーション）に対して「自分のデータへのアクセス」を許可する。
• クライアントは、認可サーバに対して「ユーザの代わりに動いてよいか」を問い合わせる。
• 認可サーバは、ユーザを認証した上でトークンを発行し、そのトークンを用いてクライアントがリソースサーバにアクセスできるようにする。

代表的なフローとしては、Authorization Code フロー（特に PKCE 付き）が広く利用されている。本書では、主にこのフローを前提として説明を行い、Implicit Flow など古いパターンの詳細な解説は扱わない。図2-4 に Authorization Code フローの概要を示す。

図2-4: OAuth2 Authorization Code フロー（概要）

sequenceDiagram
    participant U as User
    participant C as Client (App)
    participant AS as Authorization Server
    participant RS as Resource Server

    U->>C: 保護リソースへのアクセス要求
    C->>AS: 認可リクエスト（ブラウザリダイレクト）
    U->>AS: 認証・同意
    AS-->>C: 認可コード (via redirect_uri)
    C->>AS: 認可コード + クライアント認証
    AS-->>C: アクセストークン (+ ID トークン)
    C->>RS: API リクエスト (Authorization: Bearer ...)
    RS-->>C: 保護リソース

図2-4 を読む際は、ブラウザリダイレクトでやり取りされる要素と、クライアント（バックエンド）から認可サーバへ直接送られる要素を区別すると整理しやすい。

1. クライアントがブラウザを通じて認可サーバにリダイレクトし、ユーザ認証・同意を取得する。
2. 認可サーバはクライアントに認可コードを返却する。
3. クライアントはバックエンドから認可コードとクライアントシークレット（または PKCE のコードベリファイア）を用いてトークンエンドポイントにアクセスし、アクセストークンを取得する。
4. クライアントはアクセストークンを用いてリソースサーバに API リクエストを送信する。

Pentest では、次のような観点が重要となる。

• クライアントシークレットやリダイレクト URI の管理が適切か
• 認可コードの再利用や盗聴が攻撃に繋がらない設計となっているか
• スコープが適切に制限されているか（過剰な権限の付与がないか）

OpenID Connect（OIDC）

OIDC は OAuth2 をベースとした認証レイヤであり、ユーザの「ID」を表現する ID トークン（通常は JWT）を定義する。これにより、クライアントは「誰であるか」を標準化された形式で取得できる。

OIDC では、ID トークンが持つクレーム（sub、iss、aud、nonce など）が重要であり、特に次の点がセキュリティ上の焦点となる。

• aud（オーディエンス）が想定するクライアント ID と一致しているか
• nonce を利用してリプレイ攻撃を防いでいるか
• iss が信頼する IdP（Identity Provider / ID プロバイダ）であることを検証しているか

認証と認可の混同

実務では、「OAuth2 によるログイン」や「API トークンによる認証」という表現がしばしば混在し、認証と認可の境界が不明瞭になることがある。Pentest の観点では、次の点を明確に切り分けて評価する。

• 誰であるかを証明する仕組み（認証）
• 何をしてよいかを制御する仕組み（認可）

たとえば、「アクセストークンを持っていれば、組織内すべてのリソースにアクセスできる」設計は、認可の粒度が粗すぎる状態であり、API Security Top 10 における典型的なリスク（BOLA や過剰権限）と直結する。

本書の Part 4 では、これらの理論を前提として、実際のトークン検証や認可不備のテスト手法を詳細に扱う。

次に読む章

• 典型的な Web 脆弱性の整理

本章のポイント

• JWT は header.payload.signature の形式で表現され、署名アルゴリズムやクレーム検証の妥当性が Pentest の主要な確認点となる。
• OAuth2 は認可のフレームワークであり、ロール、Authorization Code（PKCE 付き）フロー、リダイレクト URI・スコープ等の設計がリスクに直結する。
• OIDC は OAuth2 をベースとした認証レイヤであり、ID トークンのクレーム（iss / aud / nonce 等）と、認証・認可の切り分けが重要である。