MS_OAuthSecurityConsiderationsRole - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

OAuth 2.0 Security Considerations (Role)

概要

OAuth 2.0 Threat Model and Security Considerationsの
各種役割に適用されるセキュリティ考慮事項。

Authorization Server

code

対象

code を使用したアクセストークン・リクエスト

脅威

code の不正使用（オンライン推測などによる）

対策

  • 不正使用が検出された場合、トークンを自動失効する。
  • jti で、トークンを識別して
    OAuth 2.0 Token Revocationで失効。

補足（code は 1 回限りが原則）: 現在の
Security BCP（RFC 9700）および
OAuth 2.1 では、code は
1 回限りの使用で、2 回目の提示を検出したら
その code から発行済みのトークンをすべて失効させることが求められる。
元ページの「不正使用が検出された場合、トークンを自動失効する」が、
そのまま標準の要求事項になった形である。
加えて PKCE が必須化され、
code を盗んでも code_verifier が無ければ交換できなくなった。

refresh_token

対象

refresh_token を使用したアクセストークン・リクエスト

脅威

refresh_token の不正使用

  • refresh_token の漏洩 / 盗難
  • Device の盗難
  • 脆弱な、侵害された Client
  • クリック・ジャッキング攻撃
  • Resource Owner の偽装

対策

  • 制限付き発行

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

  • ローテーション処理の実装

    • リフレッシュ要求ごとに refresh_token 値を変更する。
    • これにより、以下の試みを自動的に検出して防止できる。
      • refresh_token を並行して使用
      • 古い refresh_token を使用

  • バインド

    • Client 識別（client_id）
    • Device 識別（DeviceID）

  • X-FRAME-OPTIONS ヘッダ
    IFRAME 防止によるクリックジャック攻撃の防止

  • OAuth 2.0 Token Revocationで失効。

補足（Refresh Token Rotation として定着した）: 「ローテーション処理」は
その後 Refresh Token Rotation という名前で標準的な実装になった。
Public Client では Security BCP が
ローテーション、または DPoP 等による
Sender-Constrained 化のいずれかを必須としている。
使い回し（同じ refresh_token の 2 回目の提示）を検知したら、
その トークン ファミリ全体を失効させるのが定石である。

補足（X-Frame-Options の後継）: X-Frame-Options は現在も
互換のために使われるが、標準としては
Content-Security-Policy の
frame-ancestors ディレクティブが後継にあたる
（複数オリジンの指定ができ、仕様上も明確に定義されている）。

Client

Client 認証

対象

  • Client の認証
  • Client（→ Authorization Server・Resource Server の各 Endpoint）

脅威

  • 脆弱な Client、
    パブリック・クライアント

    • client_secret 漏洩

  • 悪意のある Client、
    パブリック・クライアント偽装

    • XSS 攻撃
    • code フィッシング攻撃
    • オープンリダイレクタ

対策

クライアント認証により、Authorization Server・Resource Server が
Client を識別する。

  • 脆弱な Client に client_secret を発行しない。

  • パブリック・クライアントの自動認可を許可すべきでない。

  • client_id /（client_secret /）redirect_uri を要求。

    • 対象

      • 認可リクエスト
      • アクセストークン・リクエスト

    • 要件

      • インストール固有の client_secret を使用する。
        （Device にインストールする Client の場合、インストール毎に変える）

      • redirect_uri のフルパス登録・検証

      • 取り消し可能な client_id / client_secret

  • 強力なクライアント認証

補足（Public Client は「認証しない」が正解になった）:
元ページは「インストール固有の client_secret」を挙げているが、
現在の Security BCP / OAuth 2.1 では
Public Client にクライアント認証を課さず、代わりに
PKCE で code を守るという整理になっている。
配布物に埋め込んだ秘密は秘密ではない、という当然の帰結である。
Confidential Client 側は逆に強化され、
private_key_jwt や
mTLS が FAPI で必須になっている。

Client セキュリティ

対象

  • Client のセキュリティ
  • Client（→ Authorization Server の各 Endpoint）

脅威

  • 脆弱な Client に対する攻撃
    • リバース・エンジニアリング攻撃
    • Client の脆弱性に対する攻撃

対策

  • Client パッケージ内に client_secret を保存しない（デプロイごとに変更）。

  • refresh_token ストレージを信頼できるバックエンドにスワップ

  • サーバ：セキュリティ対策を実施

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

  • モバイル：

    • Device ロック（パスワード、PIN、指紋認証、顔認証）
    • 安全なローカル・ストレージに保存
      • パーソナル分離ストレージ
      • アプリケーション固有ストレージ

  • Client は UserAgent セッションに state パラメタを追加

移行メモ（脱字）: 元ページの脅威に挙がっている「リエンジ攻撃」は
「リバース・エンジニアリング攻撃」の脱字と解して補った
（OAuth 2.0 Threat Model (Role)の
「client_secret の入手」で同じ攻撃が説明されている）。

補足（「バックエンドにスワップ」は BFF のこと）:
「refresh_token ストレージを信頼できるバックエンドにスワップ」は、
現在の BFF（Backend for Frontend） そのものである。
ブラウザにはトークンを渡さず HttpOnly Cookie だけを持たせ、
トークンはサーバ側セッションに置く。
「OAuth 2.0 for Browser-Based Apps」で
第一の選択肢として整理された。

Client と Resource Owner 間のやり取り

対象

ユーザ操作

脅威

  • 一般ユーザ（Resource Owner）にとって、認可画面の意味が不明

    • 認可画面で「はい」と回答した結果を理解する専門知識を持たない。
    • 要求の文言に微妙な違いを見ることができない。

  • Device 上でのソフトウェア脆弱性の脅威は強く、緩和も困難。

    • WWW ブラウザの脆弱性
    • 人気のある Client の脆弱性

  • インストールした Client ソフトウェアの使用を制限

    • 一部の限定的な環境では実用的。
    • しかし、一般的な環境では実用的ではなく、
      事後の回復メカニズムが整備されているべき。

  • 自動再認証、認可画面非表示により、認証認可プロセスを隠す。

    • 攻撃者は、侵害されたまたは悪意のある役割上で資格情報を盗む可能性がある。

対策

  • 自動再認証、認可画面非表示の問題に解決策はなく、
    UX とセキュリティ間のトレード・オフを考慮して決定する必要がある。

  • Device にインストールした Client プロパティのアサート

    • 検証できないプロパティを明示的に指摘
    • 特定の Client へのアクセス許可に関連するリスクをエンド・ユーザーに示す。

移行メモ（読み取り）: 元ページの
「事実回復後のメカニズムが整備されているべき（？」は、
RFC 6819 の "recovery mechanisms ... after the fact" を指すと解して
「事後の回復メカニズムが整備されているべき」と読み替えた
（侵害された Client を後から失効・回収できる仕組みのこと）。

補足（現在は「検証済みクライアント」で答えている）:
「Client プロパティを検証できない」という問題に対しては、現在
**アプリ ストアの署名、OS のアテステーション（App Attest / Play Integrity）、
Software Statement（署名付きクライアント メタデータ）**といった
仕組みで「このクライアントは名乗っているとおりのものか」を
機械的に確かめる方向に進んでいる。
認可画面に「検証済み」バッジを出す IdP も多い。

Resource Server

Authorization: Bearer JWT で、大方、解決する。

Authorization Headers

対象

「認証されたリクエスト」

Authorization: Bearer XXXXX

脅威

未認証アクセス

  • 漏洩
  • または意図しない永続化

対策

Authorization ヘッダを利用し認証アクセス

  • HTTP プロキシとサーバによって認識され、特別に扱われる。
  • これにより、漏洩または意図しない永続化の可能性が低減される。

認証されたリクエスト

対象

トークン乱用

脅威

トークン乱用の防止。

対策

以下のような方法で、Client 認証を行う。

補足（現在の「記名式切符」は mTLS / DPoP）:
「トークン内の暗号化セクションに client_secret を同梱」という
元ページの案は、その後の標準では採用されなかった
（秘密そのものをトークンに入れると、トークンが漏れた時点で
秘密も漏れるため）。
現在は 公開鍵のハッシュ（cnf クレーム）をトークンに入れ、
対応する秘密鍵を持っていることを毎回証明させる方式に落ち着いている。

  • mTLS（RFC 8705）: cnf.x5t#S256 にクライアント証明書の
    サムプリントを入れる。
  • DPoP（RFC 9449）: cnf.jkt に公開鍵のサムプリントを
    入れ、リクエスト毎に DPoP ヘッダで署名する。

署名されたリクエスト

対象

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

脅威

キャプチャ＆リプレイ

対策

リクエストは

  • 一意に識別可能にする。
  • 2 回処理されないようにする。

Resource Owner

End-User 許可

対象

  • Resource Owner による Client の許可
  • Client（→ Authorization Server の各 Endpoint）

脅威

  • 脆弱な Client

  • 悪意のある Client

  • オンライン推測

  • オープンリダイレクタ

対策

  • 認証・認可の自動処理でクライアント認証を要求

  • インフォームド・デシジョン
    認証・認可画面の表示

    • Client に何の scope をどの期間許可するか？
    • Client プロパティ検証
      • Web サイト名
      • アプリケーション名

  • client_id /（client_secret /）redirect_uri へのバインディング

    • code

参考

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️