• 戻る（OAuth 2.0 Threat Model (Flow)）
  • OAuth 2.0 Threat Model (Resource Owner Password Credentials Flow)
  • OAuth 2.0 Threat Model (Authorization code Flow)
  • OAuth 2.0 Threat Model (Implicit Flow)

OAuth 2.0 Threat Model and Security Considerationsの
Flow に着目した脅威モデルのうち、ここでは唯一、
サインイン・プロセスの問題を扱う（ただし非対話）。

※ OAuth 2.0 では IdP の仕様について言及されていないので。

補足（このフローは廃止された）: Resource Owner Password Credentials
（ROPC）グラント種別は、OAuth 2.0 Security BCP
（RFC 9700）で 使用してはならないとされ、
OAuth 2.1 の仕様本体からも削除された。
本ページの脅威分析は「なぜ廃止に至ったか」の理由そのものであり、
移行を検討する際の判断材料として読むと分かりやすい。
移行先は、対話が可能なら Authorization Code + PKCE、
入力手段が乏しい機器なら
Device Authorization Grant になる。

レガシー / マイグレーションの理由でよく使用される。

• ユーザ ID / パスワードの漏洩
• 非対話的問題を突いた攻撃。

限定的に利用する。

• 基本認証から移行する過渡期
• UserAgent が Authorization Server に接続できない場合
• Client と Authorization Server が同じ組織に利用されているケース

• Resource Owner は認可プロセスを制御できない。
• Client にユーザ ID / パスワードが渡る。

悪意のある Client に scope の広いトークンが悪用され得る。

• Resource Owner は、認可プロセスを制御できない。
  故に、非対話的問題を突いた攻撃を受け易い（scope の広いトークン）。

• Client にユーザ ID / パスワードが渡る。
  故に、トークン取り消しが機能しない。

補足（MFA が成立しないのが決定打）: 元ページが挙げる
「認可プロセスを制御できない」「Client に生の資格情報が渡る」に加え、
現在最も重く見られているのは
多要素認証・リスクベース認証・パスワードレスが一切使えないという点である。
ROPC は「ID とパスワードを Client が受け取って中継する」形なので、
IdP 側が追加の画面（OTP 入力、デバイス認証、同意）を出す余地がない。
FIDO や
Passwordless の UXへ
移行できないフロー、という言い方もできる。

上記の「共通的な影響」

悪意のある Client によるユーザ ID / パスワード盗難

• Resource Owner に異なるサービスに同じ
  ユーザ ID / パスワードを使用しないように促す。
  （悪意のある Client が別のサービスにログイン可能）

• refresh_token と client_id の紐付けを検証
  （aud による Client 制限を行うことが出来る）

上記の「共通的な影響」

エンドポイントに対するユーザ ID / パスワード盗聴

• SSL/TLS を利用する。
• 平文認証を使用しない代替認証を使用する。

単一のユーザ ID / パスワードの組み合わせの開示

有効なユーザ ID / パスワードの組み合わせを推測

• 他のフローを使用する。

• サインイン

  • 安全なパスワード・ポリシーを設定する。
  • ロックアウトを使用する。
  • タールピットを使用する。
  • CAPTCHA を使用する。

• クライアント認証を併用する。

移行メモ（誤字）: 元ページの「単一のユーザ ID / パスワードの
組み合わせの啓示」は「開示」の誤りと解して修正した。

補足（ロックアウトは両刃）: ROPC は
IdP の画面を経由しないため、攻撃者は認可画面や CAPTCHA を
迂回して総当たりできる。一方でアカウント ロックを厳しくすると、
攻撃者が任意のアカウントを狙ってロックさせる
（サービス妨害）ことも容易になる。
現在は「ロックアウト」より
漏洩パスワード リストとの照合・IP 単位のスロットリング・
リスクベースの追加認証を組み合わせるのが一般的である
（そしてそれらはいずれも ROPC では実施しにくい）。

上記の「共通的な影響」

Client が十分な保護を提供していない場合、偶発的に起きる。

• 他のフローを使用する。
• （Client 側で）ログのパスワードを難読化
• （Client - AuthZ 側で）
  • 要求の機密性を確保する（TLS、VPN）
  • ダイジェスト認証を使用

すべてのユーザ ID / パスワードの開示

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

• システムのセキュリティ対策を実施
• 標準の SQL インジェクション対策を実施
• ハッシュのみを格納

補足（「ハッシュのみを格納」の中身）: パスワードは
単純なハッシュではなく、ソルト付きの低速ハッシュで保存する。
現在の推奨は Argon2id、次いで scrypt / bcrypt / PBKDF2 で、
SHA-256 などをそのまま使うのは不可である
（GPU による総当たりが現実的な速度で通るため）。

上記「ユーザ ID / パスワードのオンライン推測」を参照。

悪意のある Client が、不要に大きな scope を持ったトークンを取得できる。

悪意のある Client が、不要に大きな scope を持ったトークンを要求する。

• 他の（対話的）フローを使用する。

• 認可される scope を、

  • 当該（非対話的）フローで制限
  • Client の信頼性によって緩和
  • 任意の通知手段によって Resource Owner に通知する。

長期的認可の維持
（この場合、Resource Owner の Credential 変更も有効でない）

自動再認可で refresh_token を入手。

• 他の（対話的）フローを使用する。

• 当該フローで refresh_token の発行を

  • しない。
  • Client の信頼性によって緩和
  • 任意の通知手段によって Resource Owner に通知する。

補足（パスワード変更で失効させる）: 「Credential 変更も有効でない」
という指摘への現在の答えは、
パスワード変更・リセット時にそのユーザーの refresh_token を
一括失効させるという運用である
（多くの IdP が既定でこの挙動を持つ）。
併せて refresh_token のローテーションを行い、
使い回しを検知したらファミリごと失効させる
（Security BCP の推奨）。

• 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 (Flow)
  • OAuth 2.0 Security Best Current Practice
  • OAuth 2.1

---

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