Hello there, ('ω')ノ
SNSアカウントでログインできるWebサイトを見たことはありますか？その裏側では、ほぼ間違いなく OAuth 2.0 フレームワークが利用されています。
OAuth 2.0は利便性の高い仕組みですが、開発者が実装ミスを犯しやすいことでも知られています。そのため、攻撃者にとっては格好のターゲットです。適切に理解していないと、認証回避やユーザー情報の漏洩といった重大なセキュリティインシデントにつながる危険があります。
🔍 OAuth 2.0とは？
OAuth 2.0は、認可（authorization）の仕組みであり、厳密には「認証（authentication）」のためのプロトコルではありません。ただし、実際にはログイン機能の実装にも広く使われているため、「OAuth認証」と呼ばれることもあります。
たとえば以下のような流れです：
- ユーザーが「Googleでログイン」をクリック
- Googleが認証を行い、ユーザーをリダイレクト
- リダイレクトURLに「アクセストークン」が含まれている
- サイトはこのトークンを使ってGoogleからユーザー情報を取得
- ユーザーを自動的にログイン状態にする
⚠️ OAuth 2.0の典型的な脆弱性
1. リダイレクトURIの不備（オープンリダイレクタ）
攻撃者が自身のドメインを「リダイレクトURI」に設定できる場合、トークンが攻撃者の手に渡る可能性があります。
2. ステートパラメータの不備（CSRF）
OAuthではstateパラメータを使ってCSRF攻撃を防ぎますが、これを検証していないと、ログインセッションが乗っ取られることがあります。
3. 認証コードの漏洩
認証コードがHTTPSではなくHTTP経由でやり取りされたり、ログに残ってしまったりすることで、中間者攻撃などのリスクが生じます。
4. スコープやトークンの誤解
アクセススコープの設定が甘く、攻撃者が不要なデータにアクセスできる場合があります。
🛡 対策ポイント
redirect_uriを厳格にホワイトリスト化し、完全一致で検証するstateパラメータを使い、かつサーバ側で検証する- 通信は常にHTTPSで行う
- トークンやコードをURLに含めないように設計する（例：POSTメソッドの利用）
- OpenID Connectを利用する場合は
id_tokenの検証も怠らない
Best regards, (^^ゞ
