MS_OAuthThreatModelFlow

OAuth 2.0 Threat Model (Flow)

• 戻る（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 に着目した脅威モデル。

詳細

Authorization code

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

Implicit

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

Resource Owner Password Credentials

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

Client Credentials

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 の検証が要件になっている。

Authorization Code グラント種別

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

CSRF(XSRF)対策の実装方針

本 Wiki 内

• 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