玄関の鍵、かけたはずなのに？ IDトークン検証で「なりすまし」を防ぐ極意
こんにちは。セキュリティの世界へようこそ。今日は、モダンなWebアプリ開発で避けては通れない「OpenID Connect（OIDC）」の、少し地味だけど命取りになる「IDトークンの検証」についてお話しします。
「認証機能はライブラリを入れたから大丈夫！」と思って安心していませんか？ 実は、そのライブラリの設定で『家の鍵を自分ではなく、隣の家に渡してしまっている』ような状態になっているケースが後を絶ちません。
今日は、泥棒（攻撃者）がどうやってあなたのアプリの扉を開けようとするのか、そしてどうやってそれを防ぐのか、身近な例えで紐解いていきましょう。
—
1. IDトークンは「身分証明書」そのもの
まず、IDトークンを想像してみてください。これは、GoogleやMicrosoftといった「信頼できる警備会社（IdP：IDプロバイダー）」が発行してくれる『顔写真付きの通行証』です。
ユーザーがログインに成功すると、アプリ側にこの通行証が渡されます。アプリはこれを見て、「お、この人は本当に本人だな。中に入れてやろう」と判断するわけですね。
しかし、もし悪意のある人物が、「どこか別の場所で発行された偽の通行証」や「以前、自分のために発行された古い通行証」を提示してきたらどうなるでしょうか？
アプリ側でちゃんとチェックをしないと、攻撃者は堂々と正門から侵入してきます。これが、今回お話しする「検証漏れ」による脅威です。
—
2. 泥棒を防ぐための2つのチェックポイント：iss と aud
攻撃者が狙うのは、まさにこの通行証の「発行元」と「宛先」の確認です。これを専門用語で iss (Issuer) と aud (Audience) と呼びます。
① iss (Issuer)：発行者は本当に「信頼できる警備会社」か？
iss は「この通行証は誰が発行したか」を表す情報です。
例えば、あなたが信頼しているのは「Google」という警備会社なのに、攻撃者が「怪しい裏路地の闇サイト（悪意あるIdP）」が発行した通行証を持ってきたらどうでしょう？
「うちはGoogle以外の通行証は受け付けません！」と門前払いするのが iss の検証です。
② aud (Audience)：この通行証は「うちのアプリ宛」か？
ここが一番の盲点です。aud は「これはどこのアプリのために発行されたか」を表します。
攻撃者は、別のセキュリティが甘いアプリで自分の通行証を発行してもらい、それをそのままあなたのアプリに提示して「ほら、俺だよ！」と入り込もうとします。
これは、「A社というビルの通行証を、B社というビルの受付で見せて入ろうとする」ようなもの。アプリ側で「この通行証はうちのアプリのために発行されたものか？」をチェックしないと、他人の通行証で不正ログインが成立してしまいます。
—
3. 実装で差がつく！検証コードの書き方
では、実際にコードでどう守るのか。Node.jsのライブラリ（例：openid-clientなど）を使う場合を例に見てみましょう。多くの現場で「検証設定」を省略してしまいがちですが、ここは絶対に手を抜いてはいけません。
// 検証のサンプル（擬似コード）
const { Issuer } = require(‘openid-client’);
async function verifyToken(idToken) {
// 1. 信頼できるIdPの情報を取得（issの根拠）
const googleIssuer = await Issuer.discover(‘https://accounts.google.com’);
const client = new googleIssuer.Client({
client_id: ‘YOUR_CLIENT_ID’, // 自分のアプリに割り当てられたID
});
// 2. トークンの検証（ここが最重要！）
// verifyIdTokenメソッドは内部で以下のことを自動的に行います
// – 署名の正当性チェック
// – iss (発行元) が正しいか
// – aud (宛先) が自分のclient_idと一致するか
// – exp (有効期限) が切れていないか
const claims = await client.verifyIdToken(idToken);
console.log(‘検証成功！ユーザーID:’, claims.sub);
return claims;
}
ポイント解説
client_idの設定: これがaudのチェックに使われます。あなたのアプリの「ID」を正しく設定することで、他アプリ用の通行証を自動的に弾いてくれます。- ライブラリ任せにしない: 「ライブラリがやってくれるはず」ではなく、設定ファイルに
client_idが正しく記述されているか、issのURLがハードコードではなく適切に管理されているかを確認してください。
—
4. 最後に：セキュリティは「疑うこと」から始まる
駆け出しのエンジニアの皆さんに一番伝えておきたいのは、「届いた情報はすべて疑え」ということです。
外部から渡されるトークンは、攻撃者がどんな悪意を持って加工しているか分かりません。今回紹介した iss と aud の検証は、いわば「家の玄関にカメラと名簿を用意する」ような基本的な防犯対策です。
最初は難しく感じるかもしれませんが、一度仕組みを理解してしまえば、どんな認証システムを触る時でも「お、ちゃんと iss と aud はチェックしてるかな？」と冷静に判断できるようになります。
セキュリティは、一度作って終わりではありません。少しずつ、一歩ずつ。一緒に学んでいきましょう！質問があればいつでも聞いてくださいね。皆さんの手元から、セキュアなコードが生まれることを応援しています。
コメント