ステートレス認証のためのJSON Web Token（JWT）構造とセキュリティ標準（RFC 8725）
JWTの署名・暗号化形式と検証要件を区別し、ステートレス検証、認可、失効制御の設計上のトレードオフを説明します。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
JWTのクレーム形式と直列化の種類
JSON Web Token（JWT、RFC 7519）は、当事者間でクレームを表現するコンパクトな形式です。Base64URLエンコードは暗号化ではなく、署名付きJWSのペイロードは別途暗号化しない限り読めます。機密性が必要ならJWEなどを検討します。JWT自体が認証プロトコルやステートレスセッションを保証するわけではありません。クレームの意味と検証手順は利用するプロトコルやアプリケーションが定めます。
よく見るheader.payload.signatureの3部分形式はJWS Compact Serializationです。JWTには署名付きJWS、暗号化JWE、限定された状況での非保護表現があり、すべてが3部分とは限りません。iss、sub、aud、exp、nbf、iat、jtiは登録クレーム名で、RFC 7519は全トークンにすべてを必須としていません。署名は、期待する鍵とアルゴリズムで検証して初めて、改ざん検知や署名鍵の保有確認に役立ちます。
専門家の視点：署名検証とセッション制御は別の問題
Yaron Sheffer、David Hardt、Michael Jonesらが執筆者に含まれるIETF RFC 8725は、JWT実装のセキュリティに関するBest Current Practiceです。検証側で許可アルゴリズムを限定し、利用目的に沿ってトークンを確認するよう求めます。Auth0のPrincipal Security Engineer、Maria Vasilevskayaは2025年の記事で、自己完結型アクセストークンの失効までの時間と、短い有効期間、バックチャネルログアウト、送信者制約などの対策を説明しています。これはIDプロバイダーの実装視点であり、すべてのJWT環境で利用できる機能ではありません。
トークン形式だけでは認証・暗号化・ステートレス性は決まらない
JWTはクレーム形式です。署名付きJWSのペイロードはBase64URLで表現されるだけで秘匿されません。機密性が必要ならJWEなど暗号化形式を使います。JWTには署名付き・暗号化・非保護の形式があり、よく見る3区分はJWS Compact Serializationの形で、すべてのJWT表現ではありません。登録クレームも全項目が必須ではありません。署名が正しいだけでは利用者、API、権限に適したトークンとは言えません。アルゴリズムと鍵用途、署名、issuer、audience、時刻クレーム、アプリケーションの認可を検証します。即時失効が必要なら拒否リスト、セッション状態、イントロスペクションなどの状態管理を設計に含め、refresh-token rotationやSameSite=StrictをJWT共通の必須要件として扱わないでください。