JWTデコード（ヘッダー・ペイロード・有効期限の確認）

JWT（JSON Web Token）を貼り付けるだけでヘッダーとペイロードを整形JSONで表示し、exp/iat/nbfをJST・UTCの日時に変換。期限切れかどうかも即座に判定し、alg:noneの危険性も解説します。署名の検証は行いません。

使い方

上の欄にJWT（xxxxx.yyyyy.zzzzz の形式の文字列）を貼り付けます。
ヘッダーとペイロードが整形されたJSONとして表示され、alg（署名アルゴリズム）や exp（有効期限）などの主要クレームが一覧表示されます。
exp を含むトークンでは「有効期限内」「期限切れ」がJST・UTCの日時とあわせて即座に表示されます。

仕組み・根拠

JWT（JSON Web Token）はRFC 7519で定義された、ヘッダー・ペイロード・署名の3部分をそれぞれBase64URL（RFC 4648 §5）でエンコードし、ピリオドで連結した文字列です。ヘッダーとペイロードは単なるBase64URLエンコードのJSONであり、暗号化されているわけではないため、誰でもデコードして中身を読むことができます。このツールはBase64URLの文字列をUTF-8のバイト列として自前でデコードしており、日本語などの非ASCII文字を含むクレーム（nameなど）も正しく表示します。

exp（有効期限）・iat（発行日時）・nbf（これ以前は無効）はRFC 7519 §4.1で定義された標準クレームで、いずれもUNIXエポック秒（1970-01-01 UTCからの経過秒数）の数値です。本ツールはこれをミリ秒に換算してJSTとUTCの日時に変換し、現在時刻との差分から「あと何分」「何時間前に失効」を計算しています。

署名の検証は行いません。 JWTの署名（HMACなら共通鍵、RSA/ECDSAなら秘密鍵）を正しく検証するには鍵情報が必須ですが、これをブラウザの入力欄に貼らせることは鍵の漏えいリスクを伴うため、本ツールでは意図的に対応していません。ここで見えるのはあくまで「トークンの主張内容」であり、その内容が改ざんされていないことの証明ではない点に注意してください。

現場の落とし穴: ヘッダーの alg が none になっているトークンは、署名なしとして扱われる仕様上のアルゴリズムです。サーバー側のライブラリ設定や実装に不備があり、クライアントが指定した alg をそのまま信用してしまうと、攻撃者が alg: none に書き換えたペイロード改ざん済みトークンをそのまま受理してしまう既知の攻撃手法があります（2015年前後にCVEとして複数報告）。受信側の検証では許可するアルゴリズムを固定のホワイトリストで指定し、none を明示的に拒否する実装が推奨されます。

よくある質問

Q. デコードできますが、このトークンは本物ですか？

A. このツールでは判定できません。デコードはあくまで中身を読むだけの処理で、署名検証（真正性の確認）とは別物です。真正性はトークンを発行したサーバー側、または正しい鍵を持つ検証側でのみ確認できます。

Q. `exp` がないトークンは無効期限ということですか？

A. exp クレーム自体が任意（オプション）のため、含まれていないトークンはこのツール上では「exp クレームなし」と表示されます。実際に無期限として扱われるかはサーバー側の実装次第です。

Q. 3つの部分に分かれていないと言われました。

A. JWTは必ず「ヘッダー.ペイロード.署名」の3つをピリオドで連結した形式です。前後の空白やクォート、Bearerプレフィックスが混入していないか確認してください。