MS_OAuthThreatModel - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki
- 戻る（OAuth 2.0 セキュリティ関連トピック）
- OAuth 2.0 Threat Model and Security Considerations
- OAuth 2.0 Security Best Current Practice
- OAuth 2.0 Threat Model (Implicit Flow)
OAuth 2.0 の脅威モデルとセキュリティ考慮事項 (RFC 6819)
- OAuth 2.0 の実装にあたり、脅威モデルとセキュリティ考慮事項を列挙
- セクション４以降からの内容で、OAuth 2.0 の前提は飛ばしている。
補足（RFC 6819 と Security BCP の関係）: RFC 6819（2013 年）は
OAuth 2.0 公開当時の脅威を網羅的に洗い出した文書である。
その後に見つかった攻撃（ミックスアップ、コード注入など）と
現在の推奨事項は、後継の
「OAuth 2.0 Security Best Current Practice」
（RFC 9700）にまとめられている。
本ページは「何が脅威か」の分類、Security BCP は「今どうすべきか」を
押さえる、という読み分けになる。
OAuth 2.0 の包括的なグループ化された脅威モデル。
OAuth 2.0 Threat Model (Access)
移行メモ（アンカーの重複）: 元ページでは「Flow 毎」と「Access 毎」の
見出しに同じアンカー ID が振られていた（PukiWiki 側の記述ミス）。
移行先では見出しの文字列がそのままアンカーになるため影響はないが、
区別が付くよう見出しに対象を補った。
脅威を緩和するために推奨される対策。
OAuth 2.0 Security Considerations (General)
OAuth 2.0 Security Considerations (Role)
- SSL/TLS（サーバ証明）を利用する。
（OAuth 2.0 Security Considerations (General)を参照） - 正規の Client へ発行されたトークンの漏洩に注意。
- code（state）：code 置換攻撃が可能。
- access_token：access_token を利用可能。
-
stateを付与・検証する。 -
redirect_uri検証を行う。 - クライアント認証を行う。
-
トークン
- refresh_token
- access_token
- code
- , etc.
-
低いエントロピーの値を使用しない。
-
バインドする。
- Client（aud: client_id）
- Resource Owner（sub: sub）
- Resource Server（aud: client_id or Endpoint）
-
access_token を JWT 化する。
補足（「バインドする」の狙い）: トークンに
aud/subを入れて
「誰が・誰に向けて・誰の権限で」発行されたかを刻んでおくと、
盗まれたトークンや取り違えたトークンを受け取った側が拒否できる。
上の 3 つのバインドは、
OAuth 2.0 Threat Model (Implicit Flow) の
「access_token 置換による OAuth ログイン」への直接の対策になっている。
なおaudに Resource Server を指定する仕組みは、後に
Resource Indicators for OAuth 2.0 として
標準化された。
-
（JWT 化した場合、）Client、Resource Server でも、
-
署名検証する。
-
クレームセット検証する。
- iss（issuer）
issは署名検証があるので偽装困難 - aud（client_id）
Resource Server でもaudによるクライアント検証を行う。 - sub（ユーザ ID）
ユーザへの明示に加え、
Client、Resource Server で認証済みリクエストでsub検証するなど。
- iss（issuer）
-
-
Authorization Server を用いた access_token 検証
-
署名検証する。
-
クレームセット検証する。
- iss（issuer）
- aud（client_id）
- sub（ユーザ ID）
- jti（無効化状況）
-
クレームセットを JSON で返却
Client、Resource Server で検証を容易にする。
-
- 偽造サーバの識別
- 組み込みブラウザに注意
（組み込みブラウザについては
「OAuth 2.0 for Native Apps」「AppAuth」を参照）
- 完全な
redirect_uriの事前登録と検証 - スターターとアクセストークン・リクエストでの
redirect_uriの要求
- 悪意のあるクライアントと組み合わさる。
- その際の
scopeなど注意が必要。
- 悪意のあるクライアントが容易に登録可能。
- 悪意のあるクライアント対策の実装が必要。
（OpenID Connect - Dynamic Client Registrationの
初期アクセス トークンの節を参照）
ネイティブアプリや JS アプリのように secret を秘匿に保てないタイプ。
-
サーバより脅威が多い。
- 盗難
- リエンジ
- ストレージ
- ウィルス
- 脆弱性
-
JS アプリ（SPA）の場合は、
Implicit Flowを使用する。 -
ネイティブの場合は、
OAuth PKCEを利用する。
移行メモ（現在は逆）: 「JS アプリ（SPA）の場合は Implicit Flow を使用する」は
RFC 6819 当時（2013 年）の前提である。
その後 Implicit Flow は
OAuth 2.0 Security Best Current Practice と
OAuth 2.1 で廃止され、
現在は SPA でもネイティブと同じく Authorization Code ＋
PKCE を使うのが正しい。
元ページの記述は当時の記録として残す。
詳しくは「OAuth 2.0 for Browser-Based Apps」を参照。
-
RFC 6819 - OAuth 2.0 Threat Model and Security Considerations
https://tools.ietf.org/html/rfc6819 -
OAuth 2.0 Threat Model and Security Considerations
http://openid-foundation-japan.github.io/rfc6819.ja.html -
本 Wiki 内
Tags: IT国際標準, 認証基盤, クレームベース認証, OAuth