先に読むと理解しやすい記事：トークン・APIキー・Bearer認証 / エンコード・暗号化・ハッシュ / 電子署名・MAC（HMAC）
JWTは主張をまとめて渡すデータ形式
JWTはJSON Web Tokenの略で、利用者IDや期限などの主張をJSONの形でまとめ、受け渡すための形式です。主張の各項目をクレームと呼びます。JWTという名前だけでは、何を検証するか、どんな権限を許すかは決まりません。
代表的な署名付きJWTでは、発行者が内容に署名またはMACを付けます。受信したAPIはそれを検証し、利用者IDや期限を確認してから処理します。クレームを読めたことと、正当な認証情報だと確認したことは別です。
参照：出典 s1
よく使う署名付き形式は三つの部分からなる
JWSという署名またはMACを付ける形式のコンパクト表現では、ヘッダー、ペイロード、署名の三部分をピリオドで区切ります。前の二つにはBase64urlで表現したJSONなどが入ります。Base64urlはURLでも扱いやすい文字を使う表現方法です。
ヘッダーはアルゴリズムなど、ペイロードは利用者IDや期限など、署名部分は前の二つの改ざん検出に使う値です。次は構造の説明で、有効なトークンではありません。JWTには暗号化するJWEなどもあり、すべてが三部分とは限りません。
説明用の通信例・設定例・擬似コード
base64url(header).base64url(payload).signature
// ヘッダーの内容例
{"alg":"ES256","typ":"JWT"}
// ペイロードの内容例
{"sub":"user-42","iss":"https://login.example","aud":"photos-api","exp":2000000000}参照：出典 s1
期限と発行者と利用先は別々の条件
subは主体の識別子、issは発行者、audは想定する受信先、expは有効期限を表します。expなどのNumericDateは、1970年1月1日00:00:00 UTCからの秒数で表します。必要な項目と許可値は、利用するプロトコルやアプリの設計で決めます。
署名が正しくても、別のAPI向けのトークンを受理してよいとは限りません。photos-apiのために発行された値を支払APIが受理すると、写真用の許可で支払いの操作を受け付けるおそれがあります。署名に加えて、期待する発行者・受信先・期限などを確認します。
デコードではなく検証APIを使う
デコードは文字列から中身を取り出す操作です。攻撃者も内容を書いて符号化できるため、それだけで信用してはいけません。検証では、許可するアルゴリズムと信頼する鍵をサーバー側で決め、署名またはMACと必要なクレームを確認します。
ヘッダーのalgを無条件で採用したり、トークン内で指定された任意URLから鍵を取得したりしないようにします。kidは鍵を選ぶ識別子ですが、存在するだけで信頼を保証しません。既知の発行者の鍵から選びます。
参照：出典 s2
署名を確かめないと権限を書き換えられる
説明用の例として、APIがペイロードを読むだけでrole=adminを信用するとします。攻撃者が自分のJWTのroleを書き換えて送り、APIが署名を検証しなければ、管理者操作を許可してしまいます。
検証失敗時は処理を拒否し、検証済みのクレームだけを利用します。その後も対象データへの認可は必要です。また、署名付きJWTのペイロードは通常誰でも読めるため、パスワードなどの秘密を含めて配布しません。
期限前の失効方法は別途用意する
署名と期限だけで検証する方式では、ログアウト操作だけで盗まれたJWTを直ちに無効にできるとは限りません。短い有効期限や、サーバーで失効状態を照合する方式などを組み合わせます。
鍵を交換する場合は、既存トークンの検証に旧鍵をいつまで使うかも決めます。漏えいした鍵を受け付け続けることと、正常な更新のための移行期間は区別します。
参照：出典 s2
署名が正しくても使えない場合を考える
確認問題：署名が正しいなら、期限切れのJWTも受理してよいでしょうか。答えは違います。有効期限など、用途に必要な条件をすべて確認します。
自分の検証環境で、改ざん、期限切れ、発行者の違い、受信先の違い、許可しないアルゴリズムをそれぞれ拒否するか確認します。単にJSONを表示するデコード機能を、認証の検証機能と取り違えないようにします。
参照：出典 s2
出典・確認範囲
- [s1] JSON Web Token (JWT)IETF / RFC 7519 / 確認日 2026-11-03
- [s2] JSON Web Token Best Current PracticesIETF / RFC 8725 / 確認日 2026-11-03
通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。