【テクニカル・上級編】JWTのiat(Issued At)とnbf(Not Before)クレームの検証 – アプリケーションセキュリティ & 安全な開発防御ガイド

JWTにおける `iat` と `nbf` の「厳密な検証」が分かつ、システム寿命の正念場

多くのエンジニアがJWT（JSON Web Token）を単なる「IDカード」だと勘違いしている。だが、現場で泥をすすり、インシデントの火消しに走り回ってきた我々にとって、JWTは「タイムラインの整合性が担保されていない限り、ただの時限爆弾」に他ならない。

特に `iat` (Issued At) と `nbf` (Not Before) の検証を、「まぁ、とりあえずライブラリのデフォルトに任せておこう」と放置しているなら、それは防御を放棄しているに等しい。本稿では、なぜこの2つのクレームが、リプレイ攻撃や時刻同期の隙を突く攻撃に対して不可欠な防波堤となるのか、その深淵を紐解く。

—

1. なぜ `iat` と `nbf` が「論理的な脆弱性」となるのか

攻撃者は、ネットワークの微細なラグやサーバー間のクロックスキュー（時刻ズレ）を常に監視している。

`iat` (Issued At): トークンが「いつ生成されたか」。
`nbf` (Not Before): トークンが「いつから使用可能か」。

これらが検証されない場合、攻撃者は「未来の時刻」や「異常な過去の時刻」に生成されたトークンを意図的に注入し、セッション管理のロジックをバイパスする。特に分散システムでは、サーバーノード間でのNTP同期の遅延が数秒生じるだけで、検証ロジックが脆弱性を露呈する。

「JWTなら署名（Signature）があるから大丈夫」と過信してはいけない。署名は「改ざん」を防ぐが、「不正なタイミングでの再利用」という論理的な不備までは防げないからだ。

—

2. 実装の急所：クロックスキュー（許容誤差）の設計

ライブラリを使う際、最も重要なのは `leeway`（許容誤差）の取り扱いだ。これをゼロにするのは理想だが、現実的にはサーバー間の同期ズレを考慮し、数秒〜数十秒のバッファを持たせる必要がある。しかし、この数秒が攻撃者の「リプレイ攻撃の猶予期間」になることを忘れてはならない。

以下は、Go言語による厳密な検証実装の例だ。

package security

import (
“errors”
“time”
“github.com/golang-jwt/jwt/v5”
)

// ValidateToken は、iatとnbfを厳密に検証するアーキテクチャの核となる
func ValidateToken(tokenString string) (jwt.Token, error) {
return jwt.Parse(tokenString, func(token jwt.Token) (interface{}, error) {
// 署名アルゴリズムの強制チェック (HMAC系への脆弱性混入を防ぐ)
if _, ok := token.Method.(jwt.SigningMethodHMAC); !ok {
return nil, errors.New(“予期せぬ署名アルゴリズム”)
}
return []byte(“secret_key”), nil
},
// クレーム検証の要：許容誤差を最小限に抑える
jwt.WithLeeway(5 time.Second),
// iatの検証を強制する
jwt.WithIssuedAt(),
// nbfの検証を強制する
jwt.WithNotBefore(),
)
}

この実装のポイント

1. `WithLeeway(5 time.Second)`: これ以上のバッファは持たせない。インフラの時刻同期（PTPやChrony）を適切に行うことが大前提だ。
2. アルゴリズムの固定: `alg: none` 攻撃や、公開鍵を秘密鍵として誤認させる攻撃を、ライブラリの検証関数内で物理的に遮断する。

—

3. 生成AI時代の新たな脅威：トークンの「汚染」と検証のガードレイル

今、我々が直面しているのは、プロンプトインジェクションを通じてJWTのヘッダーやペイロードが改ざんされるリスクだ。もし、LLMがバックエンドAPIを呼び出すためのトークンを動的に生成するアーキテクチャを採用している場合、以下のガードレイルを設ける必要がある。

トークン発行の「サンドボックス化」: トークン生成をLLMのコンテキストから完全に分離し、必ず署名専用のハードウェア・セキュリティ・モジュール（HSM）またはKMSを経由させる。
短寿命化の極致: `iat` から `exp`（有効期限）までの時間を可能な限り短くし、万が一トークンが流出した際の「爆風範囲（Blast Radius）」を最小化する。

—

4. チーフホワイトハッカーとしての提言

JWTの検証は、パケットレベルのTLS暗号化とはレイヤーが異なる「アプリケーション層の免疫システム」だ。

もしあなたがセキュリティアーキテクトなら、次の監査項目をチェックリストに加えよ。
1. Clock Skewの可視化: 全ノードのNTP同期状態を監視しているか？
2. 再利用検知: `jti` (JWT ID) クレームを用いたブラックリスト（またはRedisでの使用済みID管理）は実装されているか？
3. 耐量子暗号（PQC）への備え: RSAやECDSAに依存した署名アルゴリズムを、将来的にXMSSやLMSといった量子耐性を持つ署名方式へ移行可能な設計になっているか？

技術は常に進化するが、攻撃者が狙うのは「仕様の隙間」と「実装者の怠慢」だ。`iat` や `nbf` という小さな定数一つにも、システムの生存を賭ける気概を持て。それが、真のエンジニアリングというものだ。