RFC 6819: OAuth 2.0 脅威モデルとセキュリティ考慮事項
RFC 6819 は、OAuth 2.0 の脅威モデルとセキュリティ考慮事項を包括的にまとめた文書です。OAuth 2.0 を安全に実装するための指針を提供します。
第1部: 概要編
RFC 6819 とは何か？
RFC 6819 は、OAuth 2.0 エコシステムにおけるセキュリティ脅威を体系的に分類し、それぞれの対策を提示した文書です。
RFC 6749（OAuth 2.0 Core）のセキュリティ考慮事項を大幅に拡張し、実装者が注意すべき点を詳細に解説しています。
なぜ重要なのか？
OAuth 2.0 は多くのコンポーネント（クライアント、認可サーバー、リソースサーバー）が連携するため、攻撃対象が多岐にわたります。
攻撃対象:
┌──────────┐ ┌──────────────┐ ┌──────────────┐
│ クライアント │ ←→ │ 認可サーバー │ ←→ │ リソースサーバー │
└─────┬────┘ └──────┬───────┘ └──────────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ ユーザー │ │ ネットワーク │
└──────────┘ └──────────┘
脅威のカテゴリ
RFC 6819 では、脅威を以下のカテゴリに分類しています。
| カテゴリ | 説明 |
|---|---|
| クライアント関連 | クライアントのなりすまし、資格情報の漏洩 |
| 認可エンドポイント関連 | CSRF、フィッシング、オープンリダイレクタ |
| トークンエンドポイント関連 | 認可コードの漏洩、リプレイ攻撃 |
| リソースアクセス関連 | トークンの盗用、スコープの濫用 |
| ユーザー関連 | フィッシング、セッションハイジャック |
第2部: 主要な脅威と対策
1. クライアントに対する脅威
1.1 クライアント資格情報の漏洩
脅威: client_secret が漏洩し、攻撃者がクライアントになりすます。
攻撃シナリオ:
1. ソースコードリポジトリに client_secret をコミット
2. モバイルアプリのバイナリから抽出
3. ログファイルに記録される
対策:
| 対策 | 説明 |
|---|---|
| 環境変数で管理 | ソースコードに含めない |
| シークレットマネージャー | AWS Secrets Manager, HashiCorp Vault 等 |
| パブリッククライアントでは使用しない | モバイル・SPA では PKCE を使用 |
| 定期的なローテーション | 漏洩時の影響を限定 |
1.2 パブリッククライアントのなりすまし
脅威: パブリッククライアントは client_secret を持てないため、client_id だけでは本物かどうか判断できない。
対策:
| 対策 | 説明 |
|---|---|
| PKCE | 認可コード横取り攻撃を防止 |
| redirect_uri の厳密な検証 | 完全一致で検証 |
| カスタム URL スキームの適切な使用 | com.example.app:/ 形式を推奨 |
2. 認可エンドポイントに対する脅威
2.1 CSRF（Cross-Site Request Forgery）
脅威: 攻撃者が被害者のブラウザで意図しない認可リクエストを実行させる。
攻撃シナリオ:
1. 攻撃者が認可リクエスト URL を準備
2. 被害者にリンクをクリックさせる
3. 被害者のアカウントが攻撃者のアカウントに紐づけられる
対策:
state パラメータの使用:
1. クライアントがランダムな state を生成
2. state をセッションに保存
3. 認可リクエストに state を含める
4. コールバックで state を検証
state が一致しない → リクエストを拒否
2.2 オープンリダイレクタ
脅威: 認可サーバーがオープンリダイレクタとして悪用され、認可コードが攻撃者に送信される。
攻撃シナリオ:
redirect_uri=https://legitimate-app.com/callback/../../../attacker.com/steal
パス正規化により:
redirect_uri=https://attacker.com/steal
対策:
| 対策 | 説明 |
|---|---|
| redirect_uri の完全一致検証 | プレフィックスマッチは禁止 |
| ワイルドカード禁止 | * や ? を許可しない |
| 事前登録必須 | 登録されていない URI は拒否 |
2.3 認可コードの漏洩
脅威: 認可コードが Referer ヘッダーやブラウザ履歴から漏洩する。
対策:
| 対策 | 説明 |
|---|---|
| 認可コードの一回限り使用 | 使用済みコードは即座に無効化 |
| 短い有効期限 | 数秒〜数分 |
| PKCE | 漏洩しても悪用不可 |
3. トークンエンドポイントに対する脅威
3.1 認可コードリプレイ攻撃
脅威: 盗んだ認可コードを再利用してトークンを取得する。
対策:
認可サーバーの対策:
1. 認可コードを一回使用したら無効化
2. 同じコードが再度使用されたら、
そのコードで発行されたトークン をすべて失効
3.2 トークンリクエストの改ざん
脅威: 中間者攻撃でトークンリクエストのパラメータを改ざんする。
対策:
| 対策 | 説明 |
|---|---|
| TLS 必須 | すべての通信を暗号化 |
| redirect_uri の再検証 | 認可リクエスト時と一致するか確認 |
| クライアント認証 | Confidential クライアントは認証必須 |
4. アクセストークンに対する脅威
4.1 トークンの盗用
脅威: Bearer トークンが盗まれると、攻撃者がリソースにアクセスできる。
盗用経路:
- ネットワーク傍受（TLS なしの場合）
- ログファイル
- ブラウザの履歴・キャッシュ
- XSS 攻撃
- 悪意のあるブラウザ拡張
対策:
| 対策 | 説明 |
|---|---|
| TLS 必須 | 通信の暗号化 |
| 短い有効期限 | 盗まれても影響を限定 |
| Sender-Constrained Token | DPoP / mTLS でバインド |
| トークンをログに記録しない | セキュリティ監査で確認 |
4.2 スコープの拡大
脅威: クライアントが本来必要以上のスコープを要求する。
対策:
| 対策 | 説明 |
|---|---|
| 最小権限の原則 | 必要最小限のスコープのみ付与 |
| ユーザーへの明示 | 要求されるスコープを明確に表示 |
| スコープのホワイトリスト | クライアントごとに許可スコープを制限 |
5. リフレッシュトークンに対する脅威
5.1 リフレッシュトークンの盗用
脅威: 長寿命のリフレッシュトークンが盗まれると、長期間にわ たって悪用される。
対策:
| 対策 | 説明 |
|---|---|
| トークンローテーション | 使用ごとに新しいトークンを発行 |
| Sender-Constrained | DPoP / mTLS でバインド |
| 失効メカニズム | 管理画面から失効可能に |
| 異常検知 | 同時使用の検出 |
リフレッシュトークンローテーション:
1回目: refresh_token_v1 → access_token + refresh_token_v2
2回目: refresh_token_v2 → access_token + refresh_token_v3
もし refresh_token_v1 が再使用されたら:
→ トークン漏洩の可能性
→ すべてのトークンを失効
6. ユーザーに対する脅威
6.1 フィッシング
脅威: 偽の認可画面でユーザーの資格情報を盗む。
対策:
| 対策 | 説明 |
|---|---|
| HTTPS + 正しい証明書 | ブラウザの警告を信頼 |
| 認可画面の一貫したデザイン | ユーザーが偽物を識別可能に |
| フィッシング対策教育 | URL を確認する習慣 |
6.2 クリックジャッキング
脅威: 透明な iframe で認可画面を重ね、ユーザーに意図しない操作をさせる。
対策:
HTTP ヘッダーで iframe 埋め込みを禁止:
X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'
第3部: 脅威モデルのまとめ
攻撃者の能力レベル
| レベル | 説明 | 例 |
|---|---|---|
| Web 攻撃者 | 悪意のある Web サイトを運営 | フィッシング、CSRF |
| ネットワーク攻撃者 | 通信を傍受・改ざん可能 | 中間者攻撃 |
| 悪意のあるクライアント | 正規クライアントを装う | なりすまし |
| 内部者 | システムにアクセス可能 | 資格情報の窃取 |
防御の優先度
最優先（必須）:
✅ TLS の使用
✅ state パラメータ
✅ redirect_uri の完全一致検証
✅ 認可コードの一回限り使用
高優先（強く推奨）:
✅ PKCE
✅ 短いトークン有効期限
✅ クライアント認証（Confidential クライアント）
推奨:
✅ Sender-Constrained Token（DPoP / mTLS）
✅ リフレッシュトークンローテーション
✅ 異常検知
RFC 6819 から RFC 9700 へ
RFC 6819 は 2013 年に発行されましたが、その後の知見を踏まえて RFC 9700（OAuth 2.0 Security BCP） が 2024 年に発行されました。
| RFC 6819 | RFC 9700 |
|---|---|
| 脅威と対策のカタログ | ベストプラクティスの要約 |
| Implicit Grant を許容 | Implicit Grant を禁止 |
| PKCE は言及のみ | PKCE を強く推奨 |
| 詳細な分析 | 実装指針に特化 |
新規実装では RFC 9700 を優先的に参照し、詳細な背景を知りたい場合に RFC 6819 を参照することを推奨します。