📌 あわせて読みたい: AIツールに何をどこまで許可するかの考え方はClaude CodeとCodexの使い分け(権限と承認)へ。この記事はWebアプリ側の話で、ログインの後にJWTが何を運び、受け取った側が何を確かめているのかだけを扱います(発行APIの実装手順や認証基盤の選定は扱いません)。
ログイン機能でJWTを使う場面では、この言葉が出てきます。ところが解説を読んでも、「トークンを返す」「検証する」が何を指しているのかが掴めないまま実装に入りがちです。この記事は、実装の前に、流れと役割を分けて見るための整理です。
結論:JWTは「クレームを運ぶ文字列の形式」でしかない
JWTは、JSONのクレームをJWSまたはJWEとして表現する文字列形式です。ログイン機能そのものでも、認証方式そのものでもありません。押さえるのは、次の分担です。
- 運ぶもの — クレーム(対象について表明する名前と値の組)
- 運び方 — コンパクトな文字列。RFC 7519は、HTTP AuthorizationヘッダーやURIクエリパラメータなど、容量に制約がある環境を想定した形式としてJWTを定義しています
- 受け取った側の仕事 — 署名や必要なクレームを検証してから処理する
そして重要な前提として、署名付きJWTの内容は暗号化されているとは限りません。
ログインから応答までの流れ
概念としての順序は次のとおりです。
- ログイン — 利用者が認証情報を送る
- トークン発行 — 認証に成功した側がJWTを返す
- APIリクエスト — クライアントが、以後のリクエストにそのJWTを添えて送る
- 検証 — 受信側が署名と必要なクレームを確認する
- 応答 — 検証を通った場合に、リクエストの処理へ進む
解説記事で「トークンを使う」と一言でまとめられる部分は、この4と5に分かれています。受け取っただけでは何も確かめたことにならない——ここが図にしたときに一番はっきりする点です。
クレームと署名がそれぞれ担うもの
JWTのクレームセットは、そのJWTが伝えるクレームを含むJSONオブジェクトです。クレームは、対象に関して表明する名前と値の組を指します。JWTはこのクレームを、JWSのペイロード、またはJWEの平文として表し、デジタル署名、MACによる完全性保護、暗号化を行えます。
Auth0の説明では、署名の検証は内容が他者によって改変されていないことを示すものであり、内容を他者が読めないことを示すものではないとされています。署名と暗号化は別の話である、という区別がここに現れます。
expと、受信側が検証する理由
expクレームが存在する場合、処理側はその時刻以後、そのJWTを受理してはなりません。有効期限は「書いてある」だけでは働かず、受信側が確認して初めて意味を持つということです。
Auth0の説明でも、受信したJWTは利用前に署名を適切に検証するよう案内されています。実装時は必ずRFC 7519および利用する製品の公式ドキュメントを確認してください。
JWTへ入れてはいけない情報
Auth0は、機密情報をJWT内へ保存しないよう案内しています。署名されていても暗号化されているとは限らない以上、中身は読まれうるものとして扱う、という前提から来る注意です。
なお、JWTを使えば安全なログイン機能が完成する、というものではありません。この記事は形式と流れの整理であり、実際の設計・実装では公式仕様と利用するサービスの案内に従ってください。
🔗 次に読む
- 実装をAIに任せた後、何を確認するかは「動いた」以外に確認する4つのことへ。
- AIの業務活用の全体像は生成AIの業務活用 完全ガイドへ。
※本記事は2026年7月22日確認時点のRFC 7519およびAuth0公式ドキュメントの説明に基づく整理です。本記事は特定の実装の安全性を保証するものではありません。
コメント