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 |