MS_OAuthSecurityBCP - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

OAuth 2.0 Security Best Current Practice

概要

OAuth 2, OIDC を実装するクライアントおよびサーバの
セキュリティ要件およびその他の推奨事項について説明

移行メモ（衍字）: 「[OAuth]2, [OIDC]のを実装する」の衍字を修正した。

補足（現在は RFC 9700）: 本ページが参照している
draft-ietf-oauth-security-topics は、
2025 年に RFC 9700 として発行された。
主な結論は次のとおりで、いずれも本ページの内容の延長線上にある。

  • Implicit Flow の廃止（response_type=token を使わない）
  • Resource Owner Password Credentials グラントの廃止
  • Authorization Code ＋ PKCE を必須
    （機密クライアントでも、PKCE か nonce のいずれかで注入対策を行う）
  • redirect_uri の完全一致
  • リフレッシュ トークンは送信者制約付きか、ローテーションする
  • iss パラメタによるミックスアップ対策（RFC 9207）

これらは OAuth 2.1 の草案にも取り込まれている。

詳細

クレデンシャル漏洩

Redirect URI 検証

完全一致でない場合、漏れる。

  • オープンリダイレクタ
    部分一致では QueryString の ReturnURL 等を悪用される事がある。

  • 攻撃者の Public クライアントへクレデンシャルを送る。

    • Authorization Code であれば code を盗むことができる。
    • Implicit であれば直接 Token を盗むことができる。

  • 推奨事項

    • Redirect URI の完全一致
    • 追加の推奨事項
      • コールバックがあるドメインは、オープンリダイレクタを実装しない。
      • 中間 URL を介して意図しないフラグメントをドロップする。
      • JAR(Request Object)を使用する。

HTTPリファラからのcode漏洩

  • response_mode=query の場合、HTTP リファラからの code 漏洩

  • response_mode=fragment が既定のモノは query に変更できないので漏れない。

  • 対策

    • HTML リンク属性「rel="noreferrer"」の使用
    • "referrer" メタリンク属性の使用
    • 中間ページにリダイレクト（履歴をサニタイズ）

補足（現在は既定で漏れにくい）: 主要ブラウザの既定の
Referrer-Policy は現在 strict-origin-when-cross-origin であり、
クロスオリジンにはオリジンまでしか送られない（パスとクエリは送られない）。
本節の対策は、既定が no-referrer-when-downgrade だった当時の前提である。

ブラウザ履歴からのcode漏洩

  • HTTP リファラと「≒」だが、より対策が難しい。

  • 対策

    • 1 回限りの使用
    • 期間の制限
    • 機密 Client のみ

ブラウザ履歴からのtoken漏洩

  • response_mode=fragment が既定のモノは
    query に変更できないので漏れない。

  • ...コレを破ると、こんな事態に陥る。

移行メモ（対応関係）: 「コレを破ると、こんな事態に陥る」の
「こんな事態」は、直前の
「ブラウザ履歴からの code 漏洩」と同じ状況
（履歴にトークンが残る）を指している。
詳しくは
「OAuth 2.0 Threat Model (Implicit Flow)」の
ブラウザ履歴からの access_token 漏洩を参照。

Clientが悪意のあるResourceServerにTokenを渡す。

  • 記名式トークン（PoP、Token Binding）
  • AS(Authorization Server) のメタデータ

（OAuth2.0 Proof of Possession、
Token Binding、
OpenID Connect - Discoveryを参照）

補足（現在の主流は DPoP と mTLS）: 「記名式トークン」の実装として、
現在は OAuth2.0 DPoP（アプリ層で鍵に紐づける）と
Mutual TLS（TLS クライアント証明書に紐づける）が
標準化されている。Token Binding は普及せず、事実上使われていない。

ミックスアップ攻撃によるcodeやtokenの漏洩

  • ミックスアップ攻撃とは、攻撃者のプロキシが、
    攻撃者の IdP を使用してログインするように書き換える攻撃らしい。

  • これにより以下の様な動作になる。

    • Client は攻撃者の IdP を使用するものと考える。
    • しかし、Resource Owner は正規の IdP に対してログオンする。
    • リダイレクト後、Client は正規の IdP が発行した code や token を攻撃者の IdP に送付してしまう。

  • 対策
    そもそも、攻撃者のプロキシに書き換えられないように HTTPS 使えという話。

  • 緩和策

    • iss を検証する。
    • IdP 毎に redirect_uri を分ける。

  • 参考

移行メモ（正誤）: 「攻撃者のプロシキ」→「プロキシ」、
「HTTP 使えという話」→「HTTPS 使えという話」を修正した
（前段が「HTTP を書き換えられる」という話なので、対策は HTTPS の意）。

補足（iss パラメタが標準化された）: 緩和策の「iss を検証する」は、
その後 **RFC 9207（OAuth 2.0 Authorization Server Issuer Identification）**として
標準化された。認可レスポンスに iss パラメタを含めることで、
クライアントが「どの認可サーバからの応答か」を確実に判別できる。

クレデンシャル注入

codeの注入

  • code の注入の場合、攻撃者の code か他人の code かで攻撃の内容が異なる。

    • 他人に自分のアカウントで処理させる。
    • 自分が他人のアカウントで処理できるようにする。

  • 対策

    • code と redirect_uri のバインド
    • state, nonce, verifier の適切な使用
    • Token Binding による Authorization Server と Client のバインド

tokenの注入

  • 攻撃者の code か他人の code かで攻撃の内容が異なる。

    • 他人に自分のアカウントで処理させる。
    • 自分が他人のアカウントで処理できるようにする。

  • 対策
    code と違って、code → token 変換処理でのガードは不可

    • Token Binding による token 自体への記名
    • Hybrid Flow ＋ nonce（OIDC）
    • 暗号バインディング

補足（code 注入と CSRF の違い）: state は
「自分が始めたリクエストの続きか」を確認する（CSRF 対策）のに対し、
PKCE の verifier や OIDC の nonce は
「その code / token が自分の要求に対して発行されたものか」を確認する
（注入対策）。
前者だけでは攻撃者が正規の手順で取得した code をすり替える攻撃を防げないため、
RFC 9700 では PKCE か nonce のいずれかが必須とされている。

XSRF

Private-Use URI Scheme 上書き攻撃的な。

（OAuth 2.0 for Native Appsを参照）

その他の攻撃

移行メモ（未記述）: 元ページは本節が「...。」のみで書かれていなかった。
参考にある draft（現 RFC 9700）で扱われている残りの主な項目を挙げると、

  • カウンターインテュイティブなリダイレクト（307 リダイレクトによる資格情報漏洩）
  • クリックジャッキング（認可画面の frame 埋め込み）
  • scope の昇格（トークン交換時の権限拡大）
  • リフレッシュ トークンの不正利用

となる。著者による本文が加筆された場合は置き換えること。

参考

Tags: IT国際標準, 認証基盤, クレームベース認証, OAuth

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️