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

OAuth 2.0 Threat Model and Security Considerationsの
一般的なすべての OAuth コンポーネントに適用されるセキュリティ考慮事項。

要求

• Client（UserAgent）から Authorization Server
• Client（UserAgent）から Resource Server

各種トークンの傍受攻撃または再生攻撃

• 認証情報
  • client_id / client_secret
  • ユーザ ID / パスワード
• トークン
  • refresh_token
  • access_token
  • code
  • 等

SSL/TLS（クライアント証明、サーバ証明）を利用する。

各種サーバ

• Authorization Server
• Client（Web application）
• Resource Server

偽造サーバへの誘導

• なりすまし
• プロキシ
• フィッシング

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

補足（TLS は「常時」が前提になった）: 本文書が書かれた当時は
「SSL/TLS を利用できない場合」という但し書きが随所にあるが、
現在の Security BCP（RFC 9700）は
全エンドポイントで TLS を必須としており、
平文の HTTP は選択肢から外れている。
加えて、redirect_uri も HTTPS 必須
（ネイティブ アプリの localhost / カスタム スキームは例外）である。

各種イベント

• 非対話的フローでの認可
• リフレッシュ
• 等

特定の種類の攻撃

下記により、攻撃を認識する可能性がある。

• 認可画面の表示

• Notification messages (email, SMS)
  通知はフィッシング媒介になる可能性があることに注意

• アクティビティ / イベントログ

• ユーザ・セルフケア・ポータル

各種、資格情報。

• 認証情報

  • client_id / client_secret
  • ユーザ ID / パスワード

• トークン

  • refresh_token
  • access_token
  • code
  • 等

資格情報の漏洩

認証情報を保護

• 資格情報保護のベストプラクティスを実施

  • 標準のシステムセキュリティ手段を実施する

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

  • クレデンシャルの

    • 「非」平文記憶、暗号化
    • 非対称暗号使用による Authorization Server の負荷軽減

移行メモ（意味の取れない箇所）: 元ページの
「非対称暗号使用による許可サーバ解放」は、
RFC 6819 の "asymmetric cryptography ... relieves the authorization server"
を機械的に訳したものと思われる。
原文の趣旨は
公開鍵暗号を使えば Authorization Server が秘密を預からずに済む
（＝ Authorization Server 側の秘密管理の負担が減る）である。
具体的には、client_secret の代わりに
JWT による強力なクライアント認証や
mTLS を使う話にあたる。

• 上記の「資格情報（Credentials）の漏洩」と同じ。
• 一部に、トークン・ハンドルを含む。

上記の「資格情報（Credentials）の漏洩」と同じ。

• 安全なパスワードポリシー

• 高いエントロピーを使用

  • Authorization Server によって生成
  • 128 ビット以上
  • 暗号的に強いランダム / 擬似乱数シーケンスを活用

• ロックアウトを使用する。

• タールピット（一時的ロック）を使用する。

• CAPTCHA を使用する（UX への悪影響有り）。

• code
• access_token
• refresh_token

• トークンの

  • 漏洩
    • 不正な Client、Resource Server によるトークンの不正使用
  • 再生
  • 推測

• トークン発行

  • 悪質なソフトウェアへ発行
  • 非対話型の認可タイプによる意図しない発行
  • Resource Owner Password Credentials Flowへの
    強力なトークン発行

• scope を制限
  特有のポリシーで scope を制限する。

  • ポリシー

    • クライアントのタイプ
      パブリック or コンフィデンシャル
    • サービスのタイプ
    • Resource Owner 設定

  • ポリシー＋選好

• 短い有効期限
  他のセキュリティ対策（シグネチャなど）が補完 / 強化され、
  あらゆる種類のトークンリークの影響が軽減される。

  • トークン漏洩
  • オンライン推測

• 使用回数の制限

  • トークン再生
  • オンライン推測

• 特定の役割にバインド
  これには、アサーション中の aud (audience) を使用する。

  • Client にバインド
    audience に Client の client_id を使用する。

  • Resource Server にバインド
    audience に Resource Server の Endpoint URL を使用する。

  • また、aud (audience) に scope を明示的に割り当てる。

  不正な Client、Resource Server によるトークンの不正使用を防止

• SAML、JWT

  • 自己完結型トークンに署名
  • トークンを暗号化
  • 標準アサーション・フォーマットを採用

移行メモ（コンフェデンシャル）: 元ページの「コンフェデンシャル」は
Confidential Client の意なので「コンフィデンシャル」に改めた。

補足（aud の縛りは Resource Indicators で標準化された）:
「Resource Server にバインドする」という考え方は、その後
Resource Indicators for OAuth 2.0（RFC 8707）で
resource パラメタとして標準化された。
クライアントがトークン要求時に対象 Resource Server の URI を指定し、
Authorization Server はそれを aud に反映する、という流れになる。
これにより「1 個の万能アクセストークンがあちこちで使える」状態を避けられる
（OAuth 2.0 Threat Model (Access)の
「access_token の不正使用」への回答にあたる）。

access_token

access_token の漏洩

• 送受信に SSL/TLS を利用する。
• 第三者とトークンを共有しない。
• Client の一時メモリに保持
  • Client のみアクセス可能
  • 漏洩しないよう永続化しない。

移行メモ（誤字）: 元ページの「Client のみアクセク可能」は
「アクセス可能」の誤りと解して修正した。

• 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 Security Considerations (Role)
  • OAuth 2.0 Security Best Current Practice
  • Resource Indicators for OAuth 2.0

---

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