OAuth 2.0/OIDCの「なんとなく実装」が招く地獄と、PKCEで防ぐ認証ジャックの現実
現場でコードをレビューしていると、いまだにOAuth 2.0を「単なるログインボタンの実装」だと勘違いしているエンジニアに出くわす。だが、断言しよう。その認識こそが、君のサービスを最も簡単にハックさせる入り口だ。
今日は、API認証のデファクトであるOAuth 2.0とOpenID Connect（OIDC）を、攻撃者の視点からどう守るか、その泥臭い現実を話す。
—
1. なぜ「暗黙的フロー」は死んだのか？
かつて主流だった「インプリシット（暗黙的）フロー」は、もはや過去の遺物だ。アクセストークンをURLのフラグメント（`#access_token=…`）としてブラウザに直接返すこの手法は、ブラウザの履歴やリファラー経由でトークンが漏洩するリスクがあまりに大きい。
現在の鉄則は「認可コードフロー + PKCE（Proof Key for Code Exchange）」の一択だ。
攻撃シナリオ：PKCEなき認可コードフローの末路
もしPKCEを実装していない場合、攻撃者は「認可コード」をインターセプト（中間者攻撃等）するだけで、君のアプリケーションになりすますことができる。認可コード自体は一時的なものだが、クライアントシークレットが不要な環境（SPAやモバイルアプリ）では、攻撃者がそのコードを正当なトークンリクエストにすり替えることが可能だ。
これを防ぐのがPKCEだ。クライアントが生成した「秘密の文字列（Code Verifier）」のハッシュ値を事前に送信し、トークン交換時にその実体を提示させることで、「認可コードを取得した本人」と「トークンを要求している本人」が同一であることを暗号的に証明する。
—
2. 実践：Python (Flask) でのセキュアなPKCE実装の要点
ライブラリを使うのは当然だが、内部で何が起きているかを知らなければ脆弱性は生まれる。以下は、トークン取得時の検証ロジックを簡略化したものだ。
import hashlib
import base64
import os
1. クライアント側で Code Verifier を生成（43〜128文字のランダム文字列）
def generate_code_verifier():
return base64.urlsafe_b64encode(os.urandom(40)).decode(‘utf-8’).rstrip(‘=’)
2. 認可リクエスト用に Code Challenge を生成 (SHA256ハッシュ)
def generate_code_challenge(verifier):
digest = hashlib.sha256(verifier.encode(‘utf-8’)).digest()
return base64.urlsafe_b64encode(digest).decode(‘utf-8’).rstrip(‘=’)
— サーバーサイドの検証ロジック (概念コード) —
def verify_token_request(code_verifier, stored_challenge):
# 送られてきたverifierをSHA256でハッシュ化し、保存されていたchallengeと照合
computed_challenge = generate_code_challenge(code_verifier)
if computed_challenge != stored_challenge:
raise Exception(“PKCE検証失敗：不正なクライアントからの要求です”)
return True
ポイント:
- `code_verifier` は絶対に見せてはならない。
- `code_challenge_method` は必ず `S256` を使用すること（`plain`は脆弱）。
—
3. トークン管理の「防波堤」：短寿命化とリフレッシュトークン
アクセストークンを「無期限」にしているシステムは、即刻修正が必要だ。漏洩した瞬間にゲームオーバーになる。
推奨する運用パラメーター
- アクセストークン: 5分〜15分で失効させる。APIサーバー側はステートレスに検証し、失効を早める。
- リフレッシュトークン:
- Refresh Token Rotation（リフレッシュトークンのローテーション）を導入する。
- リフレッシュトークンを使うたびに、新しいリフレッシュトークンを発行し、古いものを無効化する。
- 万が一、攻撃者が古いトークンを再利用した場合、即座にそのセッションに関連する全てのリフレッシュトークンを無効化する（不正利用検知のトリガーにする）。
—
4. インフラ層での防御：WAFとヘッダーの活用
コードだけでなく、NginxやWAFの設定でも攻撃の予兆を弾くべきだ。
Nginx設定例: 認可ヘッダーの検証とレート制限
location /api/ {
# 認可ヘッダーがないリクエストは即座に拒否
if ($http_authorization = “”) {
return 401;
}
# 認可コード交換エンドポイントへの過度なアクセスを制限 (ブルートフォース対策)
limit_req zone=auth_limit burst=5 nodelay;
}
セキュリティチーフからのアドバイス:
クラウドIAM（AWS CognitoやAuth0等）を使う場合も、「設定したから安心」ではない。「Allowlist以外のリダイレクトURIを許可していないか？」「シークレットをソースコードに埋め込んでいないか？」という視点は、どんなに便利なマネージドサービスを使っても君自身が守らなければならない最後の砦だ。
—
まとめ：結局のところ「性悪説」が一番の防壁
セキュリティとは、システムが「正しい挙動をする」ことではない。「攻撃者が悪意を持ってコードを読み解き、想定外の経路を通ろうとした時に、いかにしてそれを弾き飛ばすか」という設計思想だ。
1. PKCEは、現代の認証における必須の作法だ。
2. アクセストークンは、使い捨てのチケットだと考えろ。
3. リフレッシュトークンには、常に「追跡と無効化」のロジックを仕込め。
これらを実装するだけで、君のシステムは多くの「通りすがりの攻撃者」にとって、非常に攻略しにくい堅牢な要塞へと変わる。コードを書くとき、常に「これ、自分が攻撃者ならどうやって突破するか？」と自問自答してほしい。健闘を祈る。
コメント