OAuth 2.0 PKCEによる認可コード対策

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

OAuth 2.0 PKCEによる認可コード対策

OAuth 2.0の認可コードフローは、Webアプリケーションやモバイルアプリケーションで広く利用されています。しかし、特にクライアントシークレットを安全に保管できない「公共クライアント」（例：SPA、モバイルアプリ）においては、認可コードの横取り（Authorization Code Interception Attack）という脅威が存在します。この脅威に対抗するための標準的な対策が、PKCE（Proof Key for Code Exchange）です。

脅威モデル

公共クライアントは、その性質上、クライアントシークレットを安全に保管することが困難です。これらのクライアントで認可コードフローを利用する際、以下の脅威にさらされます。

認可コード横取り攻撃

悪意のあるアプリケーションやブラウザ拡張機能が、正規のクライアントアプリケーション宛のリダイレクトURIを乗っ取り、認可コードを横取りする攻撃です。攻撃者は横取りした認可コードと、正規クライアントの client_id を用いて、認可サーバーからアクセストークンを不正に取得しようとします。

この攻撃は、state パラメータだけでは完全には防げません。state パラメータはCSRF（クロスサイトリクエストフォージェリ）対策には有効ですが、攻撃者が認可コード自体を横取りした場合、state パラメータの検証をすり抜ける可能性があります。特に、ブラウザベースのアプリケーションにおいて、信頼できないスクリプトや拡張機能がリダイレクトされたURIを傍受するシナリオが想定されます[1]。

攻撃シナリオとPKCEによる緩和

PKCEがない場合とある場合の攻撃シナリオを比較し、PKCEがどのように攻撃を緩和するかを説明します。

攻撃シナリオ (PKCEなしの場合)

  1. ユーザーが正規クライアントで認可を開始: クライアントは認可サーバーへリクエストを送信。

  2. 認可サーバーがユーザーをリダイレクト: ユーザーは認可後、client_id と redirect_uri に基づいて、認可コードを含むリダイレクトURIへ転送されます。

  3. 攻撃者が認可コードを横取り: ユーザーのデバイスに存在する悪意のあるアプリやマルウェアが、正規クライアント宛のリダイレクトURIを傍受し、認可コードを不正に入手します。

  4. 攻撃者がアクセストークンを要求: 攻撃者は横取りした認可コードと正規クライアントの client_id を用いて、認可サーバーにアクセストークンの発行を要求します。

  5. 認可サーバーがアクセストークンを付与: PKCEがない場合、認可サーバーは要求を正規のものと誤認し、攻撃者にアクセストークンを付与してしまいます。

PKCEによる緩和 (Attack Chain)

PKCEは、認可コードの交換時にクライアントが「認可リクエスト時とトークン交換時で、同じ証明を持っている」ことを認可サーバーに確認させるメカニズムです。

graph TD
    subgraph PKCEなしの認可コード横取り攻撃
        U_NP["ユーザー"] --> |1. 認可リクエスト| AS_NP("認可サーバー");
        AS_NP --> |2. 認可コードリダイレクト| C_NP("正規クライアント");
        C_NP -.-> |3. 認可コード横取り (中間者攻撃)| A_NP["攻撃者"];
        A_NP --> |4. 横取りした認可コードとclient_idでトークン要求| AS_NP;
        AS_NP --> |5. アクセストークン付与| A_NP;
    end

    subgraph PKCEによる保護されたフロー
        U_PKCE["ユーザー"] --> |1. code_challengeを含めた認可リクエスト| AS_PKCE("認可サーバー");
        AS_PKCE --> |2. 認可コードリダイレクト| C_PKCE("正規クライアント");
        C_PKCE --> |3. アクセストークン要求 (code_verifier含)| AS_PKCE;
        AS_PKCE -- 認可サーバーでcode_challengeとcode_verifierを検証 --> V_PKCE{"PKCE検証"};
        V_PKCE -- 検証成功 --> |4a. アクセストークン付与| C_PKCE;
        V_PKCE -- 検証失敗 --> |4b. エラー応答| C_PKCE;

        A_PKCE["攻撃者"] --> |3'. 横取りした認可コードと(code_verifierなし/不一致)でトークン要求| AS_PKCE;
        AS_PKCE -- 認可サーバーでPKCE検証 --> V_PKCE;
        V_PKCE -- 検証失敗 --> |4b'. エラー応答| A_PKCE;
    end

PKCEフローでは、正規クライアントは認可リクエスト時に code_challenge を認可サーバーに送ります。その後、アクセストークン交換時には、code_verifier を送ります。認可サーバーは、受け取った code_verifier から code_challenge を再計算し、最初に受け取った code_challenge と一致するか検証します。これにより、認可コードを横取りした攻撃者は正しい code_verifier を持たないため、アクセストークンを取得できません。

検出と緩和

PKCEを導入することで、認可コード横取り攻撃に対する強固な緩和策を講じることができます。

PKCEの必須化

RFC 7636（2015年9月）で定義されたPKCEは、公共クライアントにとって認可コードフローのセキュリティを強化するための事実上の標準であり、IETF BCP 212（2020年1月）でもブラウザベースのアプリケーションにおけるPKCEの利用が推奨されています[1][2]。

code_verifier / code_challenge の生成と利用

  1. code_verifier の生成: クライアントは、セッションごとに予測不能でエントロピーの高いランダムな文字列（43文字以上128文字以下）を生成します。これはクライアントサイドで秘匿され、トークン交換時まで保持されます。

  2. code_challenge の計算: code_verifier を基に、code_challenge_method に従って code_challenge を計算します。推奨される code_challenge_method は S256 です。 code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

  3. 認可リクエスト: 認可リクエストには、code_challenge と code_challenge_method パラメータを含めます。

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
    &code_challenge=E9MelSacrZRYUo8GmEvgX-jxkoJ7_G9Xf4Wn_jQ_jQ
    &code_challenge_method=S256 HTTP/1.1

  4. アクセストークンリクエスト: 認可コードを受け取った後、トークン交換リクエストには code_verifier パラメータを含めます。

    POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&client_id=s6BhdRkqt3
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUqjPzChX_nLFCRfr`

コード例: code_verifier と code_challenge の生成 (Python)

import base64
import hashlib
import os

def generate_pkce_code_verifier(length=96):
    """
    PKCE code_verifier を生成する。
    RFC 7636 に従い、43〜128オクテットのランダムなURLセーフ文字列を生成する。
    """
    if not (43 <= length <= 128):
        raise ValueError("code_verifier の長さは43〜128オクテットでなければなりません。")

    # 32バイト (256ビット) のランダムなバイト列を生成


    # Base64 URLエンコードすると約43文字になる

    random_bytes = os.urandom(length // 4 * 3) # 43文字以上にするための目安

    # Base64 URLエンコード (パディングなし)

    code_verifier = base64.urlsafe_b64encode(random_bytes).decode('utf-8').rstrip('=')
    return code_verifier[:length] # 指定された長さに調整

def generate_pkce_code_challenge(code_verifier):
    """
    code_verifier から S256 method を使用して code_challenge を計算する。
    """

    # SHA256ハッシュを計算

    s256_hash = hashlib.sha256(code_verifier.encode('ascii')).digest()

    # Base64 URLエンコード (パディングなし)

    code_challenge = base64.urlsafe_b64encode(s256_hash).decode('utf-8').rstrip('=')
    return code_challenge

# 誤用例: 短すぎる/予測可能な code_verifier


# bad_verifier = "short" # これはPKCEの要件を満たさない

# 安全な代替例: 正しく code_verifier と code_challenge を生成

verifier = generate_pkce_code_verifier()
challenge = generate_pkce_code_challenge(verifier)

print(f"安全なcode_verifier: {verifier} (長さ: {len(verifier)})")
print(f"安全なcode_challenge (S256): {challenge}")
print(f"code_challenge_method: S256")

# 認可リクエスト例 (Bash)


# echo "GET /authorize?response_type=code&client_id=YOUR_CLIENT_ID&state=RANDOM_STATE


#     &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb


#     &code_challenge=$challenge


#     &code_challenge_method=S256 HTTP/1.1"

# アクセストークンリクエスト例 (Bash)


# echo "POST /token HTTP/1.1


# Host: server.example.com


# Content-Type: application/x-www-form-urlencoded

#


# grant_type=authorization_code&client_id=YOUR_CLIENT_ID


# &code=OBTAINED_AUTHORIZATION_CODE


# &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb


# &code_verifier=$verifier"

その他の緩和策

  • リダイレクトURIの厳格な検証: 認可サーバーは、事前に登録されたリダイレクトURIのホワイトリストと、リクエストに含まれる redirect_uri が完全に一致するかを厳格に検証する必要があります。ワイルドカードや部分一致は避けるべきです[3]。

  • state パラメータの利用: PKCEと同時にstate パラメータも利用することで、CSRF攻撃に対する保護を強化し、ユーザーのセッションと認可リクエストを紐づけることができます。

運用対策

PKCEを導入するだけでなく、運用面でも以下の対策を講じることで、セキュリティを維持・向上できます。

鍵/秘匿情報の取り扱い

  • code_verifier のライフサイクル: code_verifier はクライアント側でセッションごとに生成し、認可コードを取得してアクセストークンと交換するまで、安全なメモリまたはセキュアなストレージに保持する必要があります。認可コードフローの完了後は速やかに破棄します。

  • クライアントシークレット（機密クライアント向け）: PKCEは公共クライアント向けですが、機密クライアント（サーバーサイドアプリなど）の場合、client_secret も適切に保護する必要があります。環境変数、キーマネジメントサービス（KMS）、またはセキュアな設定管理ツールで管理し、ソースコードへのハードコードは避けます。

  • 短寿命なトークン: 認可コード、アクセストークン、リフレッシュトークンは、それぞれ有効期限を短く設定することで、漏洩時のリスクを低減します。

ローテーション

  • トークンローテーション: リフレッシュトークンは、定期的なローテーションを強制することで、漏洩したトークンが悪用される期間を短縮します。新しいアクセストークン発行時に新しいリフレッシュトークンを発行し、古いものを無効化する「Revolving Refresh Token」戦略が推奨されます。

最小権限の原則

  • スコープの制限: クライアントが必要とする最小限のスコープのみを要求するように設計します。これにより、トークンが漏洩した場合の攻撃範囲を最小限に抑えられます。

監査と監視

  • 認可サーバーログの監視:

    • 認可リクエスト、トークン交換リクエストのログを詳細に記録します。

    • PKCE検証失敗（code_challenge と code_verifier の不一致）のイベントを監視し、異常を検知した場合はアラートを発報する仕組みを構築します。

    • 不正な redirect_uri を含むリクエストも監視対象とします。

  • クライアントログの監視: クライアント側で発生するセキュリティ関連イベント（例: 認可コードの取得、トークン交換の試行）も記録し、異常な挙動がないか監視します。

現場の落とし穴

  • PKCEの実装漏れ: 公共クライアントであるにも関わらず、PKCEの実装が欠けているケースが依然として存在します。既存のアプリケーションをPKCE対応に改修する際は、テストを徹底する必要があります。

  • code_verifier の不適切な保管: code_verifier がクライアントサイドで攻撃者に推測可能、またはアクセス可能な方法で保管されている場合、PKCEの保護が無効になります。クライアントのセキュアなメモリや、Web Storage（LocalStorage/SessionStorage）を使用する際はXSS対策を万全にする必要があります。

  • state パラメータの誤用: state パラメータが単なるランダム文字列であり、ユーザーセッションと紐付けられていない場合、認可サーバーがリクエスト元の正当性を検証できなくなります。

  • リダイレクトURIの検証不備: ワイルドカード許可や不完全なパス検証は、オープンリダイレクターの脆弱性を生み、認可コード横取り攻撃を容易にします。

まとめ

OAuth 2.0 PKCEは、特に公共クライアントにおける認可コードフローのセキュリティを大幅に向上させるための必須の標準メカニズムです。認可コード横取り攻撃からアプリケーションとユーザーデータを保護するために、code_verifier と code_challenge の適切な生成と利用、厳格なリダイレクトURI検証、そしてstate パラメータの併用を徹底することが不可欠です。

運用においては、鍵/秘匿情報の適切な管理、トークンローテーション、最小権限の適用、そして異常を検出するための監査ログ監視がセキュリティ体制をより強固にします。これらの対策を複合的に実施することで、OAuth 2.0フローを安全に運用することが可能になります。

[1] IETF. “OAuth 2.0 for Browser-Based Applications (BCP)”. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-11. 最終更新日: 2024年5月9日. [2] IETF. “Proof Key for Code Exchange by OAuth Public Clients”. https://datatracker.ietf.org/doc/html/rfc7636. 公開日: 2015年9月. [3] Google Developers. “OpenID Connect & OAuth 2.0: Best practices”. https://developers.google.com/identity/protocols/oauth2/oauth-best-practices. 最終更新日: 2024年5月28日.

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました