1
Token を貼り付け
3 つの Base64URL セグメントを分割し、Header と Payload の JSON をプレーンテキストで表示します。
DEVELOP.03 JWT DECODER
JWT デコーダー
Token、Header、Payload、時刻クレームを最初の画面で確認できます。JSON と Claims はタブで切り替え、必要な場合だけ HMAC 検証を表示します。
JWT を貼り付け
Token を待っています
Header
Payload
クレーム値意味
署名と時刻の状態
§ 01
JWT を安全に確認する方法
2
時刻クレームを確認
Claims 表示で exp、nbf、iat のローカル日時と相対状態を確認し、期限切れや未有効の状態を判断します。
3
必要なら署名を検証
HS 系アルゴリズムでは共有シークレットを入力してブラウザー内で検証できます。デコードに成功しても署名が信頼できるとは限りません。
§ 02
読めることと信頼できることは別
JWT はドットで区切られた 3 つのセグメントで構成されます。Header はアルゴリズムと種類、Payload はクレーム、Signature は前 2 セグメントが変更されていないことを検証します。前 2 つは Base64URL なので、鍵がなくても読めます。
デバッグでありがちな誤りは、Payload が自然に見えるだけで Token が有効だと判断することです。実際の認証では、サーバー側で署名、発行者、対象者、時刻の範囲、許可するアルゴリズムの一覧を検証する必要があります。
§ 03
よく使う登録クレーム
クレーム
意味
確認する点
iss発行者
想定した認証サービスと一致するか
sub主体 / ユーザー
対象の主体を示しているか
aud対象者
現在のサービスを含むか
exp有効期限
現在時刻がこの値より前か
nbf有効開始
現在時刻がこの値より前でないか
iat発行日時
妥当な時間範囲にあるか
jtiToken 固有 ID
失効やリプレイ対策に使えるか
§ 04
よくある質問
Q1JWT のデコードと検証の違いは？
デコードは Base64URL を JSON に戻すだけで、誰でもできます。検証には正しいシークレットまたは公開鍵が必要で、内容が変更されていないことと信頼できる発行者から来たことを確認します。
Q2Payload は暗号化されていますか？
通常の JWT では Header と Payload はエンコードされているだけで、暗号化されていません。パスワード、秘密鍵などクライアントに見せたくない情報を入れないでください。
Q3exp、nbf、iat の意味は？
exp は有効期限、nbf は有効になる時刻、iat は発行時刻です。通常は秒単位の Unix タイムスタンプです。
Q4なぜここでは HS だけ検証するのですか？
HS256、HS384、HS512 は入力された共有シークレットを使います。RS と ES は公開鍵形式や曲線パラメーターが必要なため、不完全な安全性を示さないようデコードのみとしています。
Q5Token やシークレットは保存されますか？
いいえ。デコードと HMAC 検証は現在のページのメモリ内だけで行われ、サーバー送信やブラウザー保存はありません。