JWT デコーダー・パーサー

JWT Header と Payload を解析

署名を検証せずに JWT 内容を解析
入力
Secret 未入力のため署名は保持されます。編集後の Token は通常検証に失敗します
Header
Payload

ツール説明

JWT デコーダー・パーサーについて

JWT パーサーは JSON Web Token の Header と Payload をデコードし、alg、typ、署名状態、iss、sub、aud、iat、nbf、exp などの一般的なクレームを確認できます。

トークンはブラウザー内で解析され、編集した Header/Payload はローカルの HMAC シークレットで再署名できます。トークンは wetool.site へ送信されません。

JWT Parser の使い方

  1. header.payload.signature 形式の完全な JWT を貼り付けます。
  2. Decode を押して Header、Payload、主要クレームの要約を確認します。
  3. exp、nbf、iat を確認します。通常はエポック秒です。
  4. HMAC テスト用トークンでは secret を入力すると、編集した Header/Payload をブラウザー内で再署名できます。

よくある利用場面

  • 認証セッションのデバッグでトークンが期限切れか、まだ有効でないかかを確認する。
  • alg、typ、iss、aud、sub が API ゲートウェイやバックエンドの取り決めと一致するか確認する。
  • ペイロードの JSON を整形し、scope、role、tenant_id などアプリ固有のフィールドを探す。
  • 開発用トークンのクレームを編集し、既知の HMAC シークレットでローカルで再署名する。

JWT の構造、クレーム、署名の限界

JWT は通常 Header、Payload、Signature の 3 つの Base64URL の各部分で構成されます。Header/Payload のデコードに secret は不要ですが、トークンを信頼するには正しい key で署名検証が必要です。

  • Header: 通常 alg と typ を含み、署名アルゴリズムとトークンの種別を示します。
  • Payload: iss、sub、aud、iat、nbf、exp、アプリ固有のフィールドなどのクレームを含みます。
  • Signature: Header/Payload の改ざん防止に使われます。デコードしただけでは署名が有効とは言えません。
  • 時刻系のクレーム：iat、nbf、exp は通常ミリ秒ではなく Unix 秒です。

JWT パーサーのよくある質問

JWT デコードは verify と同じですか？
違います。デコードは Header と Payload を読むだけです。検証には、正しい秘密鍵または公開鍵で署名を確認する必要があります。
なぜ password なしで payload が読めるのですか？
JWT の Header と Payload は Base64URL エンコードであり、暗号化ではありません。通常の JWT ペイロードに機密情報を入れないでください。
exp、iat、nbf とは何ですか？
exp は有効期限、iat は発行時刻、nbf は有効化時刻を表し、多くは Unix 秒で保存されます。
Payload を編集したトークンは使えますか？
通常、再署名しなければ使えません。このツールは secret 入力時に HMAC テスト用トークンをローカルで再署名できます。
JWT はアップロードされますか？
いいえ。デコード、編集、HMAC による再署名はブラウザー内で実行され、wetool.site へ送信されません。

JWT とセッション Cookie

セッションは通常サーバー側に状態を保存し、ブラウザーにはセッション ID を渡します。JWT はトークン内に claims を持つためサービス間で便利ですが、expiration、署名鍵、ペイロード内容の管理が重要です。

JWT の署名検証と alg のチェックリスト

JWT はデコードできても信頼できるとは限りません。実際の検証では、アルゴリズム、鍵の取得元、issuer、audience、署名ポリシーを固定して確認します。

  • トークンの alg ヘッダーだけで検証アルゴリズムを選ばないでください。サーバーは設定済みの許可リストを使うべきです。
  • alg=none、HS256 と RS256 の取り違え、外部の場所を指す kid は高リスクな設定として扱います。
  • このツールは調査と HMAC テスト用トークンには便利ですが、本番環境での検証はバックエンドまたは認証ゲートウェイで行います。

exp、nbf、iat の時刻デバッグ

JWT の時刻系クレームは通常 Unix 秒です。有効期限が不自然な場合は、秒とミリ秒の取り違え、時計のずれ、タイムゾーン表示を先に確認します。

  • exp が現在のエポック秒より前ならトークンは期限切れ、nbf が現在より後ならまだ有効になっていません。
  • 13 桁のミリ秒を秒として読むと遠い未来の日付になり、10 桁の秒をミリ秒として読むと 1970 年付近になります。
  • サーバーは NTP 同期を保ち、わずかな時刻のずれは許容しますが、長すぎる猶予時間で設定ミスを隠さないでください。

関連ツール