JWT の構造とデコード（Base64Url）・改ざん検知の仕組み

JWT（JSON Web Token）をデコードしてペイロードのクレーム（Claims）を確認する手法と、「誰でも中身が読めるのに、なぜ改ざんは不可能なのか」 というセキュリティ上の構造解説です。

1. オンライン JWT デコーダー

ブラウザローカルで JWT の Header・Payload を解析し、有効期限（exp）やクレーム一覧を表示します。

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

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

JWT トークン

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

Header

Payload

署名の検証 (Signature Verification)

シークレットキー (HMAC SHA-256)

2. JWT の 3 つのパーツ構成 (`Header.Payload.Signature`)

JWT は 2 つのドット（.）で区切られた 3 つの Base64Url 文字列で構成されます。

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IlRhcm8ifQ.SignatureData...
└─────── Header ───────┘ └───────────── Payload ─────────────┘ └─ Signature ─┘

Header (ヘッダー): アルゴリズムの種類（例: HS256, RS256）とトークン種別（JWT）。
Payload (ペイロード): ユーザーID（sub）、発行者（iss）、有効期限（exp）などのデータ（Claims）。
Signature (署名): ヘッダーとペイロードをサーバーの秘密鍵で署名したハッシュ値。

3. 「エンコード（Encoding）」と「暗号化（Encryption）」の決定的な違い

JWT（JWS）の Payload は Base64Url エンコードされているだけであり、暗号化（Encryption）されていません。

概念	エンコード (Base64Url)	暗号化 (JWE / AES)
中身の閲覧	誰でもデコードして平文を読める	秘密鍵・復号鍵がないと読めない
主な目的	バイナリやUnicodeをHTTPヘッダー安全な文字列に変換する	機密データを隠蔽する
セキュリティ上の注意	パスワードやクレジットカード番号を載せてはならない	パスワードや機密トークンを保持可能

4. サーバーが「改ざん」を 100% 検知する仕組み

悪意あるユーザーがブラウザで Payload 内の権限（例: "role": "user" → "role": "admin"）を書き換えて API へ送信した場合：

1. サーバーは受信した Header と改ざんされた Payload を取得する。
2. サーバーは自らが保有する「秘密鍵（Secret Key）」を使って、再度 Signature を再計算する。
3. クライアントから届いた元の Signature と、再計算した Signature を比較する。
4. ペイロードが1文字でも変更されていると Signature が一切一致しないため、サーバーは 401 Unauthorized を返して即座に遮断する。

ツール一覧