ログイン機能を作ったりデバッグしたことがあれば、JWT に出会っているはずです —— クライアントとサーバーの間を行き来し、「誰であるか」を証明するコンパクトなトークンです。仕組みと安全な読み方を説明します。
3 つの部分
JWT はドットで連結された 3 つの Base64URL 文字列です:header.payload.signature。
- ヘッダー —— メタデータ、主に署名アルゴリズム。例:
{"alg":"HS256","typ":"JWT"}。 - ペイロード —— クレーム、ユーザーやトークンに関する JSON オブジェクト。
- 署名 —— ヘッダーとペイロードに対する暗号署名。秘密鍵(または秘密)で作られ、改ざん検出に使われます。
JWT デコーダーで前の 2 つを分割して読めます。
よくあるクレーム
ペイロードにはクレームが入り、一部は標準化されています:
sub—— サブジェクト(通常はユーザー ID)。iss—— 発行者(誰がトークンを作ったか)。iat—— 発行時刻(Unix タイムスタンプ)。exp—— 有効期限(Unix タイムスタンプ)。これを過ぎたトークンは拒否すべきです。aud—— 想定される受信者。
さらにアプリが追加する独自クレーム(ロール、メールなど)。
JWT の認証での使われ方
典型的なステートレスフロー:ログインするとサーバーが署名付き JWT を返し、クライアントは毎リクエストでそれを送ります(通常 Authorization: Bearer … ヘッダー)。サーバーは署名を検証し exp を確認 —— 有効なら、データベース参照なしにクレームを信頼します。このステートレス性が主な魅力です。
署名であって、通常は暗号化ではない
多くの JWT は署名(JWS)であり、暗号化ではありません。署名は完全性と真正性を証明しますが、ペイロードは Base64URL エンコードにすぎず 誰でも読めます。したがって:
- ペイロードに機密を入れない(パスワード、API キー、個人情報)。
- 暗号化は別物(JWE)で、はるかに稀です。
重要なセキュリティルール
- 必ずサーバー側で秘密鍵/公開鍵を使って署名を検証する。 デコード(本ツールが行うこと)は検証ではありません。
expを確認する。 期限切れトークンは拒否しなければなりません。- HS256 vs RS256: HS256 は 1 つの共有秘密、RS256 は秘密鍵で署名・公開鍵で検証 —— 複数のサービスが検証するが発行はしない場合に適します。
- 本物の秘密鍵をオンラインツールに貼らない。 クレーム確認のためのデコードは問題ありませんが、検証には鍵が必要で、自分のコードで行うべきです。
トークンを読む
認証の問題をデバッグするには —— トークンは期限切れ?ロールは正しい? —— デコードしてペイロードを確認します。無料の JWT デコーダーはヘッダーとペイロードを表示し、exp を読める時刻に変換します。すべてブラウザ内で行われ、トークンは送信されません。