JWTのデバッグ方法|トークンの中身を安全に確認する

JWT 認証 デバッグ API
結論

貼り付けるだけで中身が見える。サーバーに送らないローカル処理のツールを選ぶ。401のときはまずexp(有効期限)を確認。

JWTの構造

JWTは、Header.Payload.Signature の3つの部分をドット(.)で繋いだ形式です。

  • Header — アルゴリズム(HS256など)やトークンの種類が書かれている
  • Payload — ユーザーID、有効期限など、実際に使う情報が入っている
  • Signature — 改ざん検証用の署名

見た目は長い文字列ですが、HeaderとPayloadはBase64でエンコードされているだけなので、誰でもデコードして中身を読めます。暗号化ではないため、機密情報をPayloadに入れてはいけません。

デバッグの手順

1

JWTトークンをコピー(Bearerの後ろの部分だけ。eyJで始まる文字列)

2

JWTデコードツールの入力欄に貼り付ける

3

HeaderとPayloadが自動表示される。exp・subなどを確認する

よく見るクレーム(Payloadの中身)一覧

クレーム 意味・401のときの確認ポイント
exp 有効期限(Unix時刻)。切れていればトークン再発行が必要。401のとき真っ先に確認。
sub ユーザーIDなど。想定どおりのユーザーか確認。
iat 発行日時。いつ発行されたか。
aud 対象者。どのAPI向けのトークンか。別API用のトークンを送っていないか。

安全にデバッグするために

重要

JWTの中身はBase64で誰でもデコードできる。 パスワードやクレジットカード番号をPayloadに入れるのは絶対に避ける。デバッグ時は、トークンをサーバーに送信しないツールを選ぶ。ブラウザ内で完結するローカル処理なら、本番のトークンでも安心して確認できる。

401が出たときの確認フロー

  1. expを確認 — 有効期限が切れていないか
  2. subを確認 — 正しいユーザーのトークンか
  3. audを確認 — このAPI向けのトークンか(複数APIを使っている場合)
  4. AuthorizationヘッダーBearer の後ろに正しくトークンが入っているか

🔍 この場でJWTをデコードして中身を確認する

注意: このツールはデコードのみ行います。署名検証は行いません。改ざん検知には利用できません。

※ 入力・貼り付け時に自動でデコードされます

 
 

署名の検証 (Signature Verification)

関連記事

この記事は セキュリティ テーマの一環です。あわせて読むと理解が深まる関連記事をまとめました。

トピック記事
XSS攻撃と防御の完全ガイドXSS攻撃と防御の完全ガイド|反射型・蓄積型・DOM型の対策
CSRF対策の実装ガイドCSRF対策の実装ガイド|SameSite・Synchronizer Token・Laravel/Expressコード
Double Submit Cookie完全実装Double Submit Cookie完全実装|Synchronizer Token比較・SPA+JWT・サブドメイン攻撃
Content Security Policy (CSP) 設定ガイドContent Security Policy (CSP) 設定ガイド|XSS・クリックジャッキング対策
CSP Report-Only 段階導入ガイドCSP Report-Only 段階導入ガイド|本番を壊さずポリシーを検証する
セキュリティヘッダー一覧と設定ガイドセキュリティヘッダー一覧と設定ガイド|CSP・HSTS・Referrer-Policy・Permissions-Policy
セキュアなCookie設定ガイドセキュアなCookie設定ガイド|HttpOnly・Secure・SameSiteの使い分けとCSRF対策
CORSエラーの対処法CORSエラーの対処法|「Access-Control-Allow-Origin」で解決する
CORSプリフライトリクエストCORSプリフライトリクエスト|OPTIONSが飛ぶ条件と正しい応答
ローカル開発でCORSエラーが出る原因と3つの回避策ローカル開発でCORSエラーが出る原因と3つの回避策
OAuth2 PKCE SPA実装ガイドOAuth2 PKCE SPA実装ガイド|Authorization Code + S256 + BFFパターン
Passkeys・WebAuthn実装の基礎Passkeys・WebAuthn実装の基礎|FIDO2・Resident Key・@simplewebauthn/server