採用に向く条件
選ぶ理由
- ステートレス(サーバ側に保存不要)
- 署名で改ざん検知
- API/マイクロサービスと相性が良い
製品プロフィール
トークン形式
「誰が・何ができるか」を署名付き JSON で運ぶトークン形式。OIDC の ID トークンや API 認証で広く使われる。詳しくは Web の認証も参照。
基本情報
選定ガイド
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
採用に向く条件
事前に確認する条件
詳しい解説
JWT(JSON Web Token)は、署名付きで自己完結したトークンです。中身に「誰か」「いつまで有効か」といった情報(クレーム)を持ち、それ全体に署名が付くことで、受け取った側が改ざんを検知できます。
「自己完結」が肝で、トークン自体に必要な情報が入っているため、サーバー側にセッションを保持しなくても検証できます。
横にスクロール
JWT は 3 つの部分を Base64URL でエンコードし、ドット区切りでつないだ文字列です。
header.payload.signature
- header: 署名アルゴリズム(alg)・型(typ)
- payload: クレーム(sub 主体, exp 期限, iat 発行時刻, iss 発行者, aud 対象)
- signature: header と payload への署名
受け取った側は署名を検証し、改ざんされていないこと、exp が有効期限内であること、iss/aud が期待どおりかを確認します。サーバーに問い合わせず手元で検証できるため、ステートレスに扱えます。
署名方式には、共有秘密鍵の HMAC(HS256 など) と、公開鍵・秘密鍵の RSA/ECDSA(RS256・ES256 など) があります。発行者だけが秘密鍵を持ち、検証側は公開鍵で確認する後者は、鍵配布を伴う分散構成に向きます。
サーバー側にセッション情報を持つ伝統的な セッション方式 と対照的です。
| 観点 | JWT(トークン) | セッション |
|---|---|---|
| 状態の置き場所 | トークン自身が持つ | サーバーが保持 |
| ストア | 不要(ステートレス) | 必要(Redis 等) |
| 失効 | 難しい(期限切れ待ちが基本) | サーバー側で即時削除 |
| スケール | しやすい | 共有ストアが要る |
| 向く構成 | 複数サービス横断の API 認可 | 単一 Web アプリのログイン |
スケールしやすさと引き換えに、発行後の即時無効化が難しい、という性質を理解しておく必要があります。
複数のサーバーにまたがる API 認可や、サーバー間でセッションを共有したくない構成、OIDC の ID トークンとして広く使われます。
JWT は署名されるが暗号化はされないため、payload は誰でも読めます。機密情報は入れないこと。検証側は必ず署名を確認し、alg を none にされる攻撃や、HMAC と RSA の取り違え攻撃を防ぐため、許可するアルゴリズムをサーバー側で固定します。有効期限は短めにし、更新はリフレッシュトークンで行い、失効が必要な用途では失効リスト(denylist)や短命化で補います。
総じて JWT は、ステートレスに検証できる自己完結トークンとして分散 API 認可に強い一方、即時失効の弱さと署名検証の落とし穴を理解して使うことが重要です。
実装・運用の視点
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
API 認証
種別: トークン形式 / 目的: 認証/認可情報の運搬 / トークン/形式: 署名付き JSON
署名で改ざん検知
発行後すぐ失効できない(要設計)
向いている用途