JWT 解析ガイド：header と payload、有効期限の読み方

トークンを貼れば header と payload はすぐ読めます。ただし、デコードできたからといって本物とは限りません。正当性を判断するには、サーバー側での署名検証が必須です。

JWT の中身を見る必要があるとき

API が 401 を返し、期限切れなのか、aud が合っていないのか、署名検証で落ちているのかを切り分けたいとき、exp・aud・iss を見るのが一番速いです。外部のシングルサインオンと連携するときも、claim を読むのが唯一の手がかりになることがあります。

ログインはできているのに権限がない、という調査もよくあります。ロールがどの claim に入っているか、user.roles の下にネストしていないか、ゲートウェイが名前を変えていないか。署名の問題ではないので、payload を読めば特定できます。

3 つの部分と時刻フィールド

JWT は header.payload.signature の 3 つをドットでつないだものです。前の 2 つは Base64URL でエンコードされた JSON、最後が署名です。Base64 ではなく Base64URL で、+ を -、/ を _ に置き換え、末尾の = を省きます。そのため普通の Base64 デコーダに渡すと失敗することがあります。

exp（有効期限）、iat（発行時刻）、nbf（有効開始）はいずれも NumericDate、つまり 1970-01-01 UTC からの秒数です。ミリ秒でもローカル時刻でもありません。10 桁なら正解です。13 桁ならミリ秒が入っており、秒として読むと数万年後の日付になります。

exp は上限なので、判定時に 30〜60 秒の時計ずれを許容します
payload は Base64URL にすぎず、トークンを持つ人は誰でも読めます。個人情報や秘密情報を入れないでください
署名部分が空、または 2 段しかない場合は、完全な JWS ではありません

限界：署名を検証しないなら、検証していないのと同じ

デコーダは改ざんの有無を教えてくれません。攻撃はまさにそこを突きます。alg を none にする古い手口、RS256 を HS256 にすり替えて公開鍵を HMAC の鍵として使わせる混同攻撃、jku・x5u・kid で攻撃者の鍵を読み込ませる手口です。

サーバー側でメンテナンスされたライブラリを使い、header の alg を信じるのではなく、許可するアルゴリズムを明示的に固定してください。クライアント側で exp を読むのは、更新のタイミングを決めるには十分です。権限に関わる判断は、検証済みのサーバー側で行います。

よくある質問

JWT の解析は安全ですか？トークンを貼ると漏れませんか？

このツールの解析はすべてブラウザ内で完結し、トークンはサーバーに送られません。それでも本番環境のトークンはパスワードと同じ扱いにしてください。必要なときだけ貼り、用が済んだらページを閉じます。送信先が分からないサイトには貼らないでください。

有効な JWT ではないと表示されるのはなぜですか？

よくある原因は 3 つです。コピーの際に最後の部分が欠けた、Bearer の接頭辞が残っている、JWS ではなく JWE（5 段、暗号化）である。Base64URL はパディングを省くため、デコーダによってはエラーになります。

改ざんされたかどうかは分かりますか？

分かりません。デコードは署名を検証しないので、payload を書き換えて Base64URL で再エンコードしても表示されます。真偽を確かめるには、サーバー側で鍵を使って署名を検証し、exp・aud・iss を確認するしかありません。