OAuth/OIDCに対する攻撃
OAuth 2.0 と OIDC はセキュリティを重視して設計されていますが、 実装の誤りや設定の不備により脆弱性が生まれることがあります。 ここでは代表的な攻撃パターンと、その具体的な対策を解説します。
トークン漏洩
Critical攻撃シナリオ
XSS攻撃、安全でないストレージ、ログへの出力、リファラヘッダーなどを通じて、アクセストークンやリフレッシュトークンが第三者に漏洩する。
対策
- -トークンをlocalStorageに保存しない（HttpOnly Cookieまたはメモリ保存）
- -トークンをURLのクエリパラメータに含めない
- -ログにトークンを出力しない
- -アクセストークンの有効期限を短く設定する（5～15分）
- -トークンの失効（revocation）機能を実装する
リプレイ攻撃
High攻撃シナリオ
攻撃者が過去のリクエストやトークンを再利用して、不正にリソースにアクセスする。IDトークンの場合、過去に傍受したトークンを使って認証をバイパスする。
対策
- -nonce パラメータを使用し、IDトークンでの一致を検証する
- -認可コードは一度使用したら即座に無効化する
- -トークンの exp クレームを検証する
- -jti（JWT ID）クレームでトークンの一意性を検証する
- -TLS を使用して通信経路上での傍受を防止する
フィッシング攻撃
High攻撃シナリオ
攻撃者が正規の認可サーバーに似せた偽のログインページを作成し、ユーザーのクレデンシャルを盗む。OAuthの認可フローでは、ユーザーが外部サイトにリダイレクトされることが普通であるため、フィッシングに気づきにくい。
対策
- -redirect_uri を完全一致で検証する（ワイルドカードを使わない）
- -認可サーバーのURLが正しいことをユーザーに確認させるUI設計
- -登録済みの redirect_uri のみを許可する
- -iss パラメータ（RFC 9207）で認可サーバーの正当性を検証する
オープンリダイレクト
High攻撃シナリオ
redirect_uri の検証が不十分な場合、攻撃者が任意のURLにリダイレクトさせることで、認可コードやトークンを外部に流出させる。
対策
- -redirect_uri を事前登録し、完全一致で検証する
- -パス部分の比較にも厳密一致を使う（前方一致ではなく）
- -ワイルドカードやパターンマッチを redirect_uri の検証に使わない
- -フラグメント (#) を含む redirect_uri を拒否する
クリックジャッキング
Medium攻撃シナリオ
攻撃者が透明なiframeで認可サーバーの同意画面を埋め込み、ユーザーが気づかずに「許可」ボタンをクリックさせる。これにより、ユーザーの意図しない認可が行われる。
対策
- -認可サーバーで X-Frame-Options: DENY ヘッダーを設定する
- -Content-Security-Policy: frame-ancestors 'none' を設定する
- -フレームバスティングスクリプトを実装する
- -ユーザーの操作を必要とするインタラクティブな同意画面を使う
追加のセキュリティ推奨事項
- -すべての通信にHTTPSを使用する
- -セキュリティヘッダー（CSP, HSTS, X-Content-Type-Options）を設定する
- -定期的に依存パッケージの脆弱性をスキャンする
- -OAuthライブラリは実績のあるものを使い、自前実装は避ける
- -OAuth 2.1 のベストプラクティスに従う
- -トークンのスコープは必要最小限にする（最小権限の原則）
セキュリティ対策のまとめ
| 攻撃 | 主な対策 |
|---|---|
| CSRF | state パラメータ |
| 認可コード横取り | PKCE |
| トークン漏洩 | HttpOnly Cookie / BFF パターン |
| リプレイ攻撃 | nonce / jti / exp 検証 |
| オープンリダイレクト | redirect_uri の完全一致検証 |
| クリックジャッキング | X-Frame-Options / CSP |
次のステップ
セキュリティの基礎を理解したら、 シミュレーター で実際のOAuthフローを体験し、学んだセキュリティ機構がどのように 動作するかを確認しましょう。