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

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

• Token Endpoint (Refresh)
• Resource Server Endpoint (WebAPI)

移行メモ（表記）: 元ページの見出しは「Resources Server Endpoint」
となっていたが、他ページの表記に合わせて「Resource Server Endpoint」に
統一した。

影響は、
OAuth 2.0 Threat Model (Role)の
「refresh_token の入手」と同じ。

盗聴

• SSL/TLS の利用

• SSL/TLS の利用できない場合。

  • 有効期間を短くする。
  • スコープを制限する。

• client_id に refresh_token をバインド

すべての refresh_token の開示
（OAuth 2.0 Threat Model (Role)の
「refresh_token の入手」）

• データベースへのアクセス権を取得
• SQL インジェクション攻撃

• システムのセキュリティ対策を実施

• 標準の SQL インジェクション対策を実施

• client_id に refresh_token をバインド

影響は、
OAuth 2.0 Threat Model (Role)の
「refresh_token の入手」と同じ。

refresh_token のオンライン推測

• クライアント認証
• トークン・ハンドルに高いエントロピーを使用
• 自己完結型トークンに署名をしたアサーションを使用
• client_id に refresh_token をバインド

影響は、
OAuth 2.0 Threat Model (Role)の
「refresh_token の入手」と同じ。

Authorization Server への要求をプロキシする。
※ 偽造 Authorization Server により横取りする的な意味か。

SSL/TLS（サーバ証明）の利用

補足（後年これが「ミックスアップ攻撃」として整理された）:
元ページが「※ 〜的な意味か」と留保している攻撃は、
その後 Mix-Up Attack として明確に分類された。
複数の IdP を選べるクライアントに対し、攻撃者が
どの Authorization Server から戻ってきたかを取り違えさせ、
正規 IdP の code / token を攻撃者の IdP のトークン エンドポイントへ
送らせる、という攻撃である。
対策は TLS だけでは足りず、
認可レスポンスに発行者を明示する iss パラメタ（RFC 9207）か、
IdP ごとに redirect_uri を分ける方法が
Security BCP（RFC 9700）で要求されている。

影響は、
OAuth 2.0 Threat Model (Role)の
「access_token の入手」と同じ。

盗聴

• SSL/TLS の利用

• SSL/TLS の利用できない場合。

  • 有効期間を短くする。
  • スコープを制限する。

• client_id に access_token をバインド
  （認証されたリクエストの利用）

ユーザーデータの変更 / 破棄

攻撃者は有効な要求をキャプチャ＆リプレイ

• SSL/TLS（サーバ証明）の利用

• SSL/TLS の代替

  • 署名されたリクエストの利用
  • 若しくは nonce と timestamp を使用

影響は、
OAuth 2.0 Threat Model (Role)の
「access_token の入手」と同じ。

access_token のオンライン推測

• トークン・ハンドルに高いエントロピーを使用
• 自己完結型トークンに署名をしたアサーションを使用
• 有効期間を短くすることで更に強化される。

影響は、
OAuth 2.0 Threat Model (Role)の
「access_token の入手」と同じ。

偽造 Resource Server による access_token フィッシング

• SSL/TLS（サーバ証明）
  不明な Resource Server へ access_token を使用してリクエストしない。

• access_token の aud に対して、Endpoint を関連付ける。

  • 事前に Authorization Server が Resource Server の Endpoint URL を
    通知する必要がある。
  • Endpoint の検証ポリシーは
    • 厳密（完全一致）
    • または緩やか（たとえば、同じホスト）

• 認証されたリクエスト＋
  クライアント証明書などで、Resource Server はクライアント認証する。

• access_token の制限

  • scope を制限
  • 特定の Resource Server に制限する。

補足（現在の答えは Resource Indicators と PoP）:
「aud に Endpoint を関連付ける」「事前に通知する必要がある」という
元ページの課題意識は、その後 2 つの仕様で解決された。

• Resource Indicators for OAuth 2.0（RFC 8707）
  クライアントがトークン要求時に resource パラメタで対象を指定し、
  Authorization Server がそれを aud に反映する。
  「事前通知」を仕様として定義したもの。
• mTLS（RFC 8705） / DPoP（RFC 9449）
  トークンを持ち主の鍵に縛るため、偽造 Resource Server が
  横取りしたトークンをそのまま使い回せなくなる。

不正使用（意図していない Resource Server での利用が拡大する）。

• Resource Server が、別の Resource Server に access_token を使用してリクエスト
• Client や UserAgent が、別の Resource Server に access_token を使用してリクエスト

access_token は、特定の Resource Server に制限する（aud を使用する）。

影響は、
OAuth 2.0 Threat Model (Role)の
「access_token の入手」と同じ。

Authorization と WWW-Authenticate ヘッダの読み取り。

• Client

  • Cache-Control: no-store
    Web サーバから返されてくるコンテンツをキャッシュに記録するな、という指示。

• Resource Server

  • Cache-Control: private
    Web サーバから返されるコンテンツが 1 人のユーザのためのものであることを示す。
    • 共有キャッシュに記録されるべきではないことを表す。
    • ブラウザのキャッシュ等への記録はされる。

• 軽減

  • 有効期間を短くする。
  • スコープを制限する。

補足（TLS 前提なら proxy には見えない）: この項は
平文 HTTP のフォワード プロキシを想定した記述である。
HTTPS であれば中間プロキシはヘッダを読めないので、現在の主な関心事は
「TLS 終端した先」、すなわち
リバース プロキシ・API Gateway・CDN のログやキャッシュに
Authorization ヘッダやトークンが残らないか、という点に移っている
（API Gateway を参照）。

影響は、
OAuth 2.0 Threat Model (Role)の
「access_token の入手」と同じ。

Query String 利用時、（記録から）漏洩

• HTTP referer
• WWW サーバの要求ログ
• WWW ブラウザの履歴情報

• Authorization ヘッダまたは POST パラメタを使用する。

• 認証済みリクエストの利用
  アサーションの sub と認証済みリクエストの id を検証

• 軽減

  • 有効期間を短くする。
  • スコープを制限する。
  • ワンタイム・トークン

補足（URI へのトークン埋め込みは禁止された）:
「Authorization ヘッダを使う」という推奨は、その後
Security BCP（RFC 9700）で
クエリ文字列にアクセストークンを載せてはならないという
明確な禁止事項になった（RFC 6750 の URI Query Parameter 方式は非推奨）。
OAuth 2.1 でも同様に削除されている。

• RFC 6819 - OAuth 2.0 Threat Model and Security Considerations
  https://tools.ietf.org/html/rfc6819

• 本 Wiki 内

  • OAuth 2.0 Threat Model and Security Considerations
  • OAuth 2.0 Threat Model (Role)
  • OAuth 2.0 Security Considerations (General)
  • OAuth 2.0 Security Considerations (Role)

---

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