• 戻る（OAuth 2.0 Threat Model and Security Considerations）
  • OAuth 2.0 Threat Model (Flow)
  • OAuth 2.0 Threat Model (Role)
  • OAuth 2.0 Threat Model (Access)

OAuth 2.0 Threat Model and Security Considerationsの
Flow に着目した脅威モデル。

主に、code 漏洩にフォーカスした内容。

主に、access_token 漏洩にフォーカスした内容。

主に、サインイン・プロセスの問題にフォーカスした内容。

Resource Owner Password Credentialsで
説明したものと同様だが、
ユーザ ID / パスワードは使用しないため、
非対話的問題を突いた攻撃の考慮事項に限定される。

補足（現在残っているのはどれか）: 本ページが挙げる 4 グラント種別のうち、
Implicit と Resource Owner Password Credentials は
OAuth 2.1 で廃止された
（OAuth 2.0 Security BCP / RFC 9700 の勧告による）。
現在の選択肢は次の 3 つに整理されている。

用途	グラント種別
ユーザーが介在する（Web / SPA / ネイティブ）	Authorization Code + PKCE
ユーザーが介在しない（サーバ間）	Client Credentials
入力手段の乏しい機器（TV、CLI など）	Device Authorization Grant

従って、本ページの 4 分類は
「当時どういう脅威分析がされていたか」の記録として読むのが実用的である。

ネットでピックアップされていたもの。

Client を用いた攻撃が可能になる。

• Client なりすまし（偽装）
• 悪意のある Client の登録

• Client なりすまし（偽装）

  • client_id を盗んで、特定の Client になり済ますことができる。
  • これにより、攻撃用の Client を使用した攻撃が可能になる。

• 悪意のある Client の登録

  • する場合、悪意のある Client が登録できる。
  • Client を利用して code や token を盗むことができる。

• Client なりすまし（偽装）
  クライアント認証、redirect_uri 検証

• 悪意のある Client の登録
  クライアントの登録機能をサポートしない。

補足（登録機能を「切る」以外の選択肢）: 元ページは
「クライアントの登録機能をサポートしない」を対策としているが、
現在は Dynamic Client Registration
（RFC 7591）で 登録自体を認めたうえで統制する方式が標準化されている。
具体的には、Initial Access Token を要求して
「誰でも登録できる」状態を避け、
登録された Client には Software Statement（署名付きのメタデータ）で
素性を持たせる。
FAPI ではこの Software Statement の検証が要件になっている。

code の置換・注入（CSRF）

• 置換
  他人の access_token を取得できる可能性がある。

• 注入（CSRF）
  自分の access_token で他のユーザが操作を行える。

code を収集し、置換・注入（CSRF）の攻撃を行う。

• 置換

  • 自分の Client を使用して、他人の code を収集する。
  • 他人の code を収集して、自分のフロー中に埋め込む（置換）。

• 注入（CSRF）

  • 攻撃対象の Client を使用して、自分の code を収集する。
  • 自分の code を収集して、他人のフロー中に埋め込む（注入（CSRF））。

• 置換
  クライアント認証、redirect_uri 検証に対策を施す。

• 注入（CSRF）
  Client に CSRF 対策を施す。

  認可エンドポイントへ遷移する際に state パラメタを付与する。
  そして、Redirect エンドポイントで state パラメタをチェックする。

補足（state だけでは code 注入は防げない）: state は
リダイレクトが自分の始めたフローに対応するかを確かめる仕組みで、
「知らないうちにフローを開始させられる」CSRF は防げるが、
攻撃者が自分で正規に開始したフローの code を差し替える
code injection は止められない（state も一緒に差し替えられるため）。
これに対する現在の標準的な対策は次の 2 つで、
Security BCP（RFC 9700）が要求している。

• PKCE（RFC 7636）
  トークン リクエストに code_verifier を要求し、
  code を開始したクライアント自身に縛る。
• iss パラメタ（RFC 9207）
  認可レスポンスに発行者を明示し、
  複数 IdP 構成での取り違え（ミックスアップ攻撃）を防ぐ。

CSRF(XSRF)対策の実装方針

• OAuth 2.0 Threat Model and Security Considerations
• OAuth 2.0 Threat Model (Authorization code Flow)
• OAuth 2.0 Threat Model (Implicit Flow)
• OAuth 2.0 Threat Model (Resource Owner Password Credentials Flow)
• OAuth 2.0 Security Best Current Practice

---

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