JWTとは
JWT（JSON Web Token）は、クレーム（情報）をJSONで表すための規格です。Web認証でよく見るのは、JWS Compact Serializationを使った署名付きJWTで、アクセストークンとして使われることがあります。
一般的な署名付きJWTは暗号化されたものではありません。 Base64URLで表現されたヘッダーとペイロードは読めるため、パスワード、個人情報、秘密情報を入れません。
一般的な署名付きJWTの構造
JWS Compact SerializationのJWTは、ピリオドで区切られた三つの部分です。
base64url(header).base64url(payload).base64url(signature)
署名は、途中で内容が書き換えられていないことを確認するためのものです。署名が正しくても、発行者、対象者、期限が期待どおりかは検証側で確認する必要があります。
暗号化されたJWTにはJWE Compact Serializationが使われることがあり、ピリオドで区切られた五つの部分を持ちます。三部分という説明はJWS形式に限られます。
検証で確認すること
- 許可した署名アルゴリズムを検証側で固定する
- 信頼する鍵で署名を検証する
iss（発行者）とaud（対象者）を期待値と照合するexp、必要ならnbfを確認する- 用途ごとにトークンの種類・鍵・検証規則を分ける
ヘッダーのalgを見て検証方法を自動的に選ぶ設計は避けます。RFC 8725は、許可するアルゴリズムを明示し、入力の型と用途を検証することを求めています。
アクセストークンとリフレッシュトークン
| 種類 | 役割 | 注意点 |
|---|---|---|
| アクセストークン | APIへの短期間のアクセスを示す | 漏えい時の影響を抑えるため短い有効期限にする |
| リフレッシュトークン | 新しいアクセストークンを取得する | より強く保護し、失効・ローテーションを設計する |
リフレッシュトークンは「JWTにすれば安全」ではありません。発行元で失効状態、利用者、端末、ローテーション後の再利用を管理できるようにします。保存場所はブラウザ、モバイル、サーバーで脅威が異なるため、認証基盤の推奨構成に従います。
よくある誤り
- JWTの中身を秘密だと考える
- 署名だけを確認し、
iss・aud・期限を確認しない - API用とパスワード再設定用のトークンを同じ検証規則で受け入れる
- 盗まれたトークンを失効できない設計にする
まとめ
JWTは便利な形式ですが、署名が保証する範囲は限られます。アルゴリズムと発行者・対象者・期限を明示的に検証し、アクセストークンとリフレッシュトークンを別の役割として設計します。
参考リソース
関連記事
- JWTのdecodeはverifyではない - ライブラリで署名とclaimsを検証する実践
- マイクロサービスでJWTが使われる理由 - audience・鍵配布・失効を複数サービスで設計する
- Authorizationヘッダーの基本
- APIセキュリティ
PR
PR
