JWTデコーダーで分かること
署名付きのコンパクトなJSON Web Tokenは、通常、ピリオドで区切られた三つの部分から成ります。最初がヘッダー、次がペイロード、最後が署名です。このツールは、前の二つのBase64url文字列をUTF-8のJSONとして読み、記載内容を表示します。三番目の署名はここでは検証しません。符号化を元に戻すだけでは、誰が発行したか、改ざんされていないか、サーバーが受け入れるかは証明できません。ヘッダーにはアルゴリズム名、ペイロードには発行者、対象者、主体、アプリ固有の値が入ることがあります。表示値は、適切な検証が終わるまで信頼できない入力として扱ってください。入力したトークンはブラウザー内にとどまります。
exp、nbf、iatの時刻の読み方
JWTのexp、nbf、iatなどの時刻は、Unix時間の起点からの秒数を表すNumericDateを使います。2,000,000,000という値は秒であり、ミリ秒ではありません。デコーダーは元の数値の横に、人が読めるUTC日時を表示します。期限切れ、利用開始前、発行時刻の不一致を調べる際に役立ちます。ただし表示日時はペイロードの主張を解釈しただけで、有効性の確認結果ではありません。例のトークンを入力し、expと変換後のUTC日時を比べてください。生成側が誤って13桁のミリ秒値を書いた場合、日時が不自然に遠い未来になったり、扱える範囲を超えたりします。意味を確かめず数字を調整せず、生成側を修正します。ログとの照合にはUTCを使います。
不具合を調べる手順
管理された開発環境からテスト用トークンを取り出し、想定した発行者、対象者、主体が含まれるか確認します。リクエストが失敗した時刻とexp、nbfを比較します。ペイロードが正しく見えてもサーバーに拒否されたなら、サーバー側の署名検証、鍵の選択、アプリの検証方針を調べてください。このデコーダーだけでは受理の可否を判断できません。ペイロードは暗号化ではなく符号化なので、トークンを持つ人なら氏名などの私的な情報を読めます。本物のアクセストークンを公開チケット、画面写真、URL、共有例に入れないでください。処理はブラウザー内で行われますが、表示結果をコピーして共有すれば情報が広まります。
対象外の形式と信頼上の注意
五つの部分を持つ暗号化JWEは、この三部分の署名付きトークン用デコーダーの対象ではありません。壊れたBase64url、無効なUTF-8、オブジェクトでないJSONヘッダーは、黙って修正せず拒否します。ツールは鍵の取得、JWS署名の検証、許可アルゴリズムの制限、期待する対象者との比較、時計のずれの許容判定を行いません。これらには適切に設定した検証ライブラリが必要です。復号したように見える内容にadminの役割があっても、権限を認めてはいけません。改ざんされたトークンでも、無効な署名とともにもっともらしい役割を表示できます。expが未来でも、発行者、対象者、失効や別の規則によって拒否されます。構造の理解に使い、信頼の判断には使わないでください。