JWT ― 読む・検証する・許可するを分ける

三つの部分を分解し、クレームへズーム。署名だけで終わらない検証と、期限・ログアウトの違いを解説します。

JWTは、クレームを運ぶ形式

JWT（JSON Web Token）は、発行者や有効期限などの情報をコンパクトに運ぶための形式です。情報の項目をクレームと呼びます。JWTという名前自体が、ログイン方式や認可ルールを意味するわけではありません。RFC 7519

この教材では、よく見かけるJWS Compact形式の署名またはMAC付きJWTを中心に扱います。ドットで区切られた三つの部分が特徴です。

JWTには暗号化されたJWE形式などもあります。「すべてのJWTが三分割で中身も読める」と一般化しないでください。

base64url(header).base64url(payload).base64url(signature)

ヘッダーはアルゴリズムなど、ペイロードはクレーム、三つ目は署名値またはMACを表します。図では一枚のトークンが三枚に分かれます。

JWS形式のヘッダーとペイロードはBase64urlで表現されます。エンコードは暗号化ではありません。 手に入れた人が読めるので、パスワードや秘密鍵を入れてはいけません。

デコードできたことと、信用してよいことは別です。まだ署名・MACやクレームの検証をしていません。JWS Compact形式

図ではペイロードへ寄って、判断に使う項目を見ます。

exp などのNumericDateはUnix時刻の秒です。JavaScriptのミリ秒と混同しないでください。どのクレームを必須にするかは、JWTを使うプロトコルやアプリの要件で決まります。登録済みクレーム

受け手は、想定したアルゴリズムと信頼する鍵で署名・MACを検証し、発行者・対象・時刻などの条件を確認します。ヘッダーに書かれた alg をそのまま信じて、何でも受け入れてはいけません。

受信 → 形式の検査 → 署名 / MACの検証
     → iss / aud / exp 等の検証 → 用途の確認

この矢印は検証項目を説明するためのものです。実装には適切な検証ライブラリを使い、未検証のクレームに基づく操作を先に実行しません。JWTのセキュリティ指針

写真API向けに発行されたトークンを、決済APIに持ち込んだとします。発行者と署名が本物でも、aud が自分を対象にしていなければ、その用途では拒否します。

図では同じトークンが二つのAPIへ向かい、宛先が合う側だけが通ります。JWTの検証は「署名が合う」の一問で終わりません。

別のプロトコル向けのJWTを受け入れないことも重要です。例えばOIDCのIDトークンを、そのまま任意のAPI用アクセストークンの代わりにはできません。用途の混同を防ぐ

有効な署名と未来の exp があれば、オフライン検証をする受け手は、利用者がログアウトした事実をそのJWTだけから知れない場合があります。

短い有効期限、セッション照合、失効リスト、トークンの状態を問い合わせる仕組みなどを、必要な即時性に応じて組み合わせます。JWTを採用しただけで、サーバーの状態管理が一切不要になるわけではありません。

また、Bearerトークンは持つ人が使えてしまうため、漏らさない扱いが必要です。JWTかどうかという形式の話と、所持者が使えるという性質の話は分けて考えます。Bearer Tokenの性質

答えはその文字列だけでは判断できません。誰でも文字列を作り、Base64urlで表現できます。適切な検証を通したうえで、その発行者がどの情報を保証するか、自分のアプリで何を許すかを決めます。

JWTは情報を運ぶ器です。OAuthはアクセスを委ねる仕組み、OIDCは認証結果を伝える仕組みで、JWTをその中で使うことがあります。

「読む」「検証する」「許可する」の三段階を区別できれば、JWTという見た目に引きずられずに設計を読めます。