JWTの中身を確認する方法|改ざんが検知される仕組み

JWT セキュリティ 認証
結論

JWTの中身は誰でもデコードできる(暗号化ではない)。ただし署名があるため改ざんはできない

JWTの構造

JWTは Header.Payload.Signature の3つをドット(.)で繋いだ文字列です。

  • Header — アルゴリズム情報(HS256など)
  • Payload — ユーザーID、有効期限などの実データ
  • Signature — 改ざん検知用の署名

HeaderとPayloadは Base64Urlエンコードされているだけ なので、デコードすれば中身が読めます。

暗号化(Encryption) エンコード(Encoding)
鍵がないと元に戻せない 誰でも元に戻せる
目的:中身を隠す 目的:データ形式の変換
重要

JWTにパスワードやカード番号を含めるのは絶対NG。含めるのはユーザーIDや有効期限など、漏れてもクリティカルではない情報のみ。

デコードして中身を確認する

例えば、以下のようなJWTの場合:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IlRhcm8ifQ.xxxxx

2番目の部分(ペイロード)をBase64デコードすると:

{
  "sub": "1234",
  "name": "Taro"
}

「認証が通らない」「権限が反映されない」といった不具合のデバッグでは、まずペイロードの中身を確認するのが第一歩です。

改ざんが検知される仕組み

「ペイロードを書き換えたらどうなるか?」——サーバーが署名で弾きます。

サーバーはJWT発行時に、秘密鍵を使ってHeaderとPayloadからシグネチャを計算しています。ペイロードが1文字でも変わると計算結果が変わるため、送られてきた署名と一致しなくなります。

結果:401 Unauthorized が返される。

🔍 この場で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