「nonceはただのランダム文字列ではない」：OIDCにおけるリプレイ攻撃とCSRFを根絶する実装の極意
現場でコードレビューをしていると、OpenID Connect (OIDC) の実装で nonce パラメータを「なんとなく適当な文字列を入れておけばいいもの」と誤解しているエンジニアによく出くわす。
はっきり言おう。それは「家の玄関にダミーの鍵穴をつけているだけ」に等しい。なぜなら、攻撃者はその「ダミー」を解析し、正規の認証フローを横取り（リプレイ）する準備を虎視眈々と進めているからだ。今日は、OIDCにおける nonce の真の役割と、現場で絶対に外してはいけない防御の要所を解説する。
—
1. なぜ nonce なのか？ 攻撃者の視点から見るリスク
OIDCにおいて、nonce は「一度きりの使い捨てチケット」だ。
リプレイ攻撃のメカニズム
攻撃者が狙うのは、認証サーバーからクライアント（あなたのアプリ）に送られてくる「IDトークン」だ。もしアプリ側でこのトークンの使い回しをチェックしていなければ、攻撃者は盗聴やブラウザ履歴から取得した有効なIDトークンを、あたかも自分がログインしたかのように再送（リプレイ）できる。
state パラメータとの役割分担
よく混同されるが、state は CSRF対策（認証フロー自体のすり替え防止）であり、nonce は IDトークンのリプレイ対策（トークンの内容が今のリクエストと合致しているか確認）だ。これらは両輪であり、片方だけでは屋台骨が崩れる。
—
2. 実装の鉄則：Python (Flask) での検証サンプル
理論は理解しても、実装が甘ければ意味がない。以下は、IDトークンを受け取った際に nonce を検証する、現場でそのまま使えるセキュアな実装例だ。
import secrets
import jwt # PyJWTを使用
def verify_id_token(id_token, stored_nonce, client_id, issuer):
“””
IDトークンの検証ロジック
“””
try:
# 1. 署名検証と標準的なクレームの確認
payload = jwt.decode(
id_token,
key=”SECRET_KEY_OR_PUBLIC_KEY”,
algorithms=[“RS256”],
audience=client_id,
issuer=issuer
)
# 2. 【最重要】nonceの検証
# IDトークン内の ‘nonce’ クレームが、セッションに保存しておいた値と一致するか確認する
if payload.get(‘nonce’) != stored_nonce:
raise ValueError(“Nonce mismatch! リプレイ攻撃の可能性があります。”)
return payload
except jwt.ExpiredSignatureError:
# トークンの有効期限切れ
return None
except Exception as e:
# ログに詳細を残し、開発者にアラートを飛ばす
print(f”セキュリティエラー: {e}”)
return None
認証開始時に生成するnonceは必ず暗号学的に安全なものを使う
def generate_nonce():
return secrets.token_urlsafe(16)
実装のポイント
- セッションへの保存: 認証リクエスト時に
nonceを生成し、必ずサーバー側のセッション（またはSecure; HttpOnlyなクッキー）に保存すること。クライアント側に隠そうとしても改ざんされるリスクがある。 - 比較処理: 必ず
==での厳密比較を行うこと。
—
3. インフラ・アーキテクチャの盲点：WAFとヘッダー設定
コードが完璧でも、HTTP層で隙を作ってはならない。特にOAuth/OIDCのコールバックエンドポイントは攻撃の入り口になりやすいため、Nginxレベルで保護をかける。
Nginx設定例: 認証コールバックURLへの保護
location /callback {
# 認証フロー以外の不要なパラメータによる汚染を防ぐ
# 必要に応じて、Content-Security-Policyでリダイレクト先を制限
add_header Content-Security-Policy “default-src ‘self’;”;
# 不正なメソッドの遮断
if ($request_method !~ ^(GET|POST)$ ) {
return 405;
}
}
また、WAF（AWS WAFなど）を利用している場合、IDトークン（JWT）自体が非常に長いため、Size Constraints を緩和しつつ、SQLインジェクション対策ルールを適切に適用しておく必要がある。ただし、JWTの構造を壊さないよう、カスタムルールの適用には注意が必要だ。
—
4. 最後に：現場のエンジニアへ
セキュリティは「チェックボックスを埋める作業」ではない。
「もし自分が攻撃者だったら、このトークンをどう使い回すか？」「nonceを空にしたら、どこでエラーが出るか？」という破壊的な思考実験を常に繰り返してほしい。
システムは複雑になればなるほど、どこかに必ず綻びが生じる。しかし、今回解説した nonce の厳密な検証と state によるCSRF対策を徹底するだけで、認証系の脆弱性の少なくとも半分は無効化できる。
「動けばいい」ではなく「攻撃者のモチベーションを削ぐ設計」を、今日からコードに落とし込んでいこう。それが、我々エンジニアの誇りだ。
コメント