「信頼できない鍵」を受け取っていませんか？IDトークン検証でハマる落とし穴
こんにちは！セキュリティの世界へようこそ。
日々、コードを書いたりインフラを整えたりしていると、「認証なんてライブラリに任せればOKでしょ？」と思いたくなるものですよね。でも、ちょっと待ってください。そのライブラリが「何をチェックすべきか」を知らないまま使っていると、実は泥棒に玄関の鍵を渡しているのと同じ状況を作ってしまう可能性があるんです。
今回は、OAuth 2.0 / OpenID Connect (OIDC) の心臓部、「IDトークン」の検証について、プロの視点から優しく、でも本質を突いて解説します。
—
1. IDトークンは「身分証明書」である
まず、IDトークンを「身分証明書」だと想像してみてください。
あなたがイベント会場の警備員だとします。ある人がやってきて、手書きの証明書を見せました。
- iss (Issuer / 発行者): 「これは『Google』という役所が発行しました」と書いてある。
- aud (Audience / 対象読者): 「これは『このイベント会場』宛てですよ」と書いてある。
もし、このチェックを怠ったらどうなるでしょう？
悪い人が「別の街の役所（悪意のあるサイト）」で適当に作った偽造証明書を持ってきても、あなたは「お、証明書持ってるな、通れ！」と入れてしまいますよね。これがなりすましの入り口です。
—
2. なぜ iss と aud の検証が「命」なのか
攻撃者は、あなたが「ちゃんと中身を確認していないこと」をよーく知っています。
- iss（発行者）の検証漏れ:
攻撃者が自前のOIDCサーバーを立てて、「私はGoogleになりすましているサーバーです！」という証明書を配ります。あなたが iss を確認していないと、「Googleから来た証明書」と区別がつきません。
- aud（対象読者）の検証漏れ:
これはもっと巧妙です。攻撃者が、Googleを使って「別のアプリ（攻撃者のアプリ）」にログインし、そこから発行された正当なトークンを盗んで、あなたのサービスに使い回す手法です（Confused Deputy Problemと言います）。
「このトークンは『攻撃者のアプリ』宛てなのに、私のサービスで使おうとしている！」と気づけるかどうかが、あなたの防御力の分かれ目です。
—
3. 実装チェックリスト：泥棒を入れないために
多くのモダンなライブラリ（oidc-client-ts や passport-openidconnect など）は検証機能を持っていますが、設定を忘れていたら意味がありません。 以下の項目が設定されているか、今すぐ確認しましょう。
実装時の確認ポイント
1. 署名の検証: トークンが改ざんされていないか（公開鍵で検証）。
2. issの検証: 信頼している発行者（例: https://accounts.google.com）以外なら即座に拒否。
3. audの検証: あなたのアプリに割り当てられた Client ID と一致するかをチェック。
4. exp（有効期限）の検証: 期限切れの古い証明書を握りしめていないか。
サンプルコード（Node.js/JavaScriptでのイメージ）
// ライブラリの設定例：最低限これだけは守りましょう
const verifyToken = async (idToken) => {
const client = await issuer.Client.discover(‘https://accounts.google.com’);
// verifyメソッドは内部で署名・iss・audを検証してくれます
const claims = await client.verifyIdToken(idToken, {
// 自分のアプリのクライアントIDを必ず指定する
audience: ‘your-client-id-here’,
// ここでissを明示的に指定して、怪しい発行者を弾く
issuer: ‘https://accounts.google.com’
});
console.log(‘検証成功！ユーザーID:’, claims.sub);
};
—
4. 最後に：セキュリティは「疑う」ことから始まる
「ライブラリがやってくれているはずだ」という思い込みは、開発者にとって一番の盲点です。
家の鍵をかけるとき、「鍵さえかかっていれば大丈夫」と思って、窓を開けっ放しにしたりはしませんよね？それと同じで、IDトークンという鍵を受け取ったら、必ず「誰が発行したか」「誰宛てのものか」を指差し確認する。 このひと手間で、あなたのサービスは格段に堅牢になります。
もしコードの中で aud や iss の検証設定が見当たらない場合は、すぐにドキュメントを読み直して設定を追加してください。
セキュリティは完璧を目指すのではなく、「攻撃者の手間を増やす」積み重ねです。一つずつ、確実に防犯を強化していきましょう。応援しています！
コメント