JWTデコーダー

JSON Web Tokenは、ピリオドで結合された3つのBase64URLエンコードされたセグメントです: 署名アルゴリズムとトークンの種類を記述するヘッダー、実際のクレーム — トークンが誰を識別するか、いつ失効するか、どんな権限を与えるか — を含むペイロード、そして秘密鍵または秘密鍵を使って最初の2つのセグメントに対して計算された署名です。デコード — このツールが行うこと — とは、最初の2つのセグメントをBase64URLデコードして読みやすいJSONに戻すことを意味します。3番目のセグメントについては、生の符号化された値を露出させる以上のことは何も語りません。その署名を検証するには本物の署名の秘密鍵が必要であり、ブラウザベースのツールがそれを貼り付けるよう求めることは決してあってはならないからです。

この区別 — デコードと検証 — は、JWTデバッグツールについて理解すべき最も重要な単一のことです。デコードはトークンが*主張していること*を教えてくれます。検証はそれらの主張が*信頼できるか*を教えてくれます。期待される発行者によって署名が生成されたことを確認するためにです。トークンは完璧にデコードされ、管理者アクセスを主張するペイロードを表示することができますが、実際の署名鍵に対して署名を確認する何かが決してなければ、それは完全に偽造されている可能性があります。

ヘッダーとペイロードは暗号化ではなくエンコードされています — Base64URLは秘密が関与しない可逆な変換であるため、ネットワークトラフィックを傍受するか、ブラウザストレージを読むか、直接受け取るかにかかわらず、トークンを入手した誰でも、鍵を一切必要とせずにペイロードをデコードして中のすべてのクレームを読むことができます。まさにこれが、JWTペイロードを識別子と非機密のクレーム — ユーザーID、ロール、失効時刻 — に限定し、パスワード、クレジットカード番号、その他の機密データをトークンの中に直接置かないという標準的な助言の理由です。トークンの形式それ自体は何の機密性も提供しないためです。

標準のタイムスタンプクレームはUnix時間 — 1970年1月1日からの秒数を数える単純な整数 — として保存されており、これは機械が比較するには効率的ですが、目視でトークンをデバッグする人には一目では読めません。`1735689600`を「2025年1月1日 00:00:00 UTC」に手で変換するのは、時間に追われた状況で、特にタイムゾーンをまたぐと間違いやすい、小さくエラーの起きやすい計算そのものです。この3つのクレームを実際のローカル日付としてレンダリングし、トークンが現在失効しているか、有効か、まだアクティブでないかを直接示すことで、そうでなければ二次的な計算を伴うデバッグセッションが、即座で読みやすい答えに変わります。