JWTのjti（JWT ID）クレーム

jti（JWT ID）クレームは、特定のJWTに一意の識別子を提供します。その主な目的は、同じトークンが複数回使用されること（リプレイ攻撃）を防ぐことです。jtiの値は、異なるトークンに同じ値が偶然割り当てられる確率が無視できるほど小さい方法で割り当てられなければなりません。

形式と生成:

{
  "sub": "user123",
  "jti": "550e8400-e29b-41d4-a716-446655440000",
  "iat": 1700000000,
  "exp": 1700003600
}

仕様ではjtiの特定の形式は規定されていませんが、UUID（v4またはv7）が最も一般的な選択肢です。暗号学的にランダムな文字列、自動インクリメントのデータベースID、またはタイムスタンプとランダムコンポーネントを組み合わせた複合値を使用する実装もあります。重要な要件は、発行者のドメイン内での一意性です。

リプレイ攻撃の防止:

リプレイ攻撃を防ぐために、サーバーは既に確認したjti値のストアを維持します。トークンが到着すると、サーバーはそのjtiがストアに存在するかチェックします。存在する場合、トークンはリプレイとして拒否されます。存在しない場合、サーバーはトークンを処理し、jtiをストアに追加します。ストアはトークンのexp時刻が過ぎるまでエントリを保持するだけでよく、その後トークンは期限切れとして拒否されるためです。

ストレージの考慮事項:

jtiトラッキングの主な課題はストレージのオーバーヘッドです。数百万のトークンを発行する高トラフィックシステムでは、完全なjtiレジストリの維持には大きなメモリまたはデータベース容量が必要です。TTLベースの有効期限を持つRedisは、対応するトークンの期限が切れると自動的にエントリが期限切れになるため、人気のあるソリューションです。ブルームフィルターは、わずかな偽陽性率と引き換えにメモリ使用量を削減できます。

jtiを使用すべきタイミング:

すべてのアプリケーションにjtiが必要なわけではありません。ワンタイムユーストークン（パスワードリセットリンクなど）、リプレイが二重支払いを引き起こす可能性のある金融トランザクション、トークンの窃取が深刻な懸念となる高セキュリティ環境で最も有用です。短期間のアクセストークンを使用する標準的なAPI認証では、jtiストアの維持コストがセキュリティ上のメリットを上回る場合があります。