JWTとは何か：3パート構造の基礎

JWT（JSON Web Token、RFC 7519で標準化されたトークン形式）は、Header・Payload・Signatureの3つをBase64URLエンコードし、ドット.で連結した文字列です。サーバー側に状態を持たずに「このトークンは確かに自分が発行した」と検証できる点が最大の特徴です。

JWTは単独の仕様ではなく姉妹仕様の上に成り立ちます。署名はJWS（RFC 7515）、暗号化はJWE（RFC 7516）、利用可能な暗号アルゴリズムの定義はJWA（RFC 7518）が担当します。普段「JWT」と呼んでいるトークンの大半は、正確にはJWS（署名付きJWT）です。

Header alg / typ . Payload claims (iss/exp...) . Signature alg(Header+Payload) xxxxx.yyyyy.zzzzz 各パートは Base64URL エンコード（暗号化ではない＝中身は誰でも読める）
図1: JWT（JWS）の3パート構造。Base64URLは可逆エンコードであり、機密情報をPayloadに入れてはいけない。

登録済みクレームと署名アルゴリズムの選び方

Payloadには標準で7つの登録済みクレーム（iss発行者 / sub主体 / aud対象者 / exp有効期限 / nbf有効開始 / iat発行時刻 / jti一意ID）が定義されています。とくにexpとaudの検証は必須です。Headerに何が入っているかはJWTデコーダーですぐ確認できます。

署名アルゴリズムは対称鍵（HMAC系）か非対称鍵（公開鍵系）かで運用が大きく変わります。2026年のグリーンフィールド（新規）実装では、鍵サイズが小さく高速なES256、または次世代標準のEdDSAが推奨されます。

表1: 主要な署名アルゴリズムの比較（2026年時点）
項目HS256RS256ES256EdDSA
鍵種別対称（共有秘密鍵）非対称（RSA）非対称（ECDSA）非対称（Edwards曲線）
鍵サイズ目安256bit以上2048〜4096bit256bit256bit
マイクロサービス不向き（鍵共有が必要）向く向く向く
演算速度最速遅い速い最速クラス
2026年の位置づけ限定用途可推奨追加推奨

HMACの共有秘密鍵は人間が覚えるパスワードではなく、256bit以上のランダム値を使ってください。鍵生成にはパスワード生成、ハッシュの確認にはMD5/SHAハッシュ生成が役立ちます。

JWT vs セッション認証：使い分け

JWTはステートレス（サーバーに状態を持たない）なためスケールアウトが容易で、DBへアクセスできないエッジランタイム（Cloudflare WorkersやVercel Edge Functions）でも検証できます。反面、発行済みトークンの即時失効が構造的に困難という弱点があります。

表2: JWT認証とセッション認証の比較
観点JWT（ステートレス）セッション（ステートフル）
サーバー状態持たないDB/Redisに保持
スケールアウト容易ストア共有が必要
即時失効困難（短TTLで緩和）容易
マイクロサービス向く難しい

2026年の最新脅威と対策

alg:none とアルゴリズム混同攻撃

最も古く、いまだに出続けているのが署名検証バイパスです。alg:noneは「署名なし」を受け付けてしまう設定ミス、アルゴリズム混同攻撃はHeaderのalgをRS256からHS256へ書き換え、公開鍵をHMAC秘密鍵として悪用する手口です。

// 悪い例: トークン側のalgを信頼してしまう
jwt.verify(token, key);

// 良い例: 許可するアルゴリズムをサーバー側で固定
jwt.verify(token, key, { algorithms: ['RS256'] });

クレーム検証の落とし穴

RFC 8725（JWT Best Current Practices、BCP 225）が現行の公式指針ですが、実装現場ではaudクレーム未検証が約65%にのぼると報告されています。同一の認証基盤が複数サービスにトークンを発行する構成では、他サービス向けトークンを受け付ける置換攻撃の入口になります。

有効期限とリフレッシュトークン戦略

即時失効が苦手なJWTでは、アクセストークンを短命にし、リフレッシュトークンで再発行する構成が事実上の標準です。リフレッシュトークンは使用のたびに再発行し旧トークンを無効化する「Rotation」を実装し、旧トークンの再利用を検知したら全セッションを失効させます。

表3: トークンの推奨有効期限（TTL）の目安
種別実務での推奨TTL参考規制値
アクセストークン15〜60分PCI DSS: 15分（不活動）
リフレッシュ（絶対）7〜14日NIST中保証: 12時間以内
リフレッシュ（アイドル）3〜7日—
アクセス期限切れ リフレッシュ送信 旧トークン無効化 ＋新規再発行 旧トークンが再利用された → 全セッション失効（盗難検知）
図2: リフレッシュトークンRotationの流れ。旧トークンの再利用検知が盗難対策の要となる。

保存場所はXSS・CSRF双方を緩和するHttpOnly Cookie＋SameSite=Strictが現時点のベストプラクティスです。kid（Key ID）をDB問い合わせやURL解決にそのまま使うとSQLi・SSRFの入口になるため、必ずホワイトリストと照合してください。

まとめ

JWTは「中身は読めるが改ざんはできない」トークンです。署名アルゴリズムをサーバー側で固定し、expとaudを必ず検証し、短いTTLとリフレッシュRotationを組み合わせる——この3点を押さえれば、2026年の主要な脅威の大半は防げます。発行されたトークンの中身はJWTデコーダーで確認しながら実装を進めましょう。