本文へスキップ

JWT 入門：デコードと検証の違いを 5 分で理解

・対象: 初学者,Web エンジニア・タグ: tool:jwt-decoder, jwt, security, authentication

「API のログインで JWT トークンって出てきたけど、これって何？」「デコードって聞くけど、暗号化されてるの？」――初めて JWT に触れるとき、誰もが感じる疑問です。

この記事では、JWT の基本構造・デコードと検証の違い・安全な運用のポイントを 5 分で理解できるようまとめました。まずはツールで実際に触ってみましょう。

1. そもそも JWT とは？

JWT（JSON Web Token） は、Web アプリや API で「このユーザーは誰か」「どんな権限を持っているか」といった情報を安全にやり取りするためのトークン（文字列）形式です。

例えば、ログイン後にサーバーが発行した JWT をクライアント（ブラウザやアプリ）が保持し、次回のリクエスト時にそのトークンを提示することで「ログイン済み」と認証されます。

  • 自己完結型：トークン自体に情報が含まれる
  • 署名付き：改ざんを検知できる
  • 広く使われている：OAuth 2.0、OpenID Connect、SaaS の API など

2. JWT の構造（Header・Payload・Signature）

JWT は「.（ドット）」で区切られた 3 つの部分で構成されます：

      eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

これを分解すると：

  • Header（ヘッダー）: アルゴリズムやトークンタイプ
  • Payload（ペイロード）: ユーザー情報や有効期限
  • Signature（署名）: 改ざんされていないかを検証するために使う

重要: Header と Payload は Base64URL エンコードされているだけで、暗号化されていません。つまり、誰でもデコードして中身を見ることができます。

3. デコードと検証の違い（最重要ポイント）

操作内容誰ができる？用途
デコードBase64URL を復号して中身を読む誰でもできるトークン内容の確認・デバッグ
検証（Verify）署名を秘密鍵/公開鍵でチェック鍵を持つ者のみ改ざん検知・真正性の保証

よくある誤解

❌ 「デコードできたから正しいトークンだ」 → 間違い！ ⭕ 「デコードは誰でもできる。検証して初めて信頼できる」 → 正解！

デコードは「中身を見る」だけ。改ざんされたトークンでも、デコードは成功します。検証を行わないと、悪意ある第三者が作った偽トークンを受け入れてしまう危険があります。

4. 使う場面・利点

JWT はこんなシーンで活躍します：

  • 認証トークン: ログイン後の状態を保持（セッションの代わり）
  • API 通信: マイクロサービス間で権限情報を受け渡し
  • Single Sign-On（SSO）: 複数サービスで共通のログイン状態を共有
  • OAuth 2.0 / OpenID Connect: アクセストークンや ID トークンとして

利点:

  • ステートレス：サーバーでセッション管理不要
  • スケーラブル：複数サーバーに分散しやすい
  • 標準化：多くのライブラリ・フレームワークが対応

5. よくある勘違い・失敗例

❌ 失敗例 1: Payload に機密情報を入れる

Payload は誰でもデコードできるため、パスワード・クレジットカード番号・個人情報を入れてはいけません。

❌ 失敗例 2: デコードだけで信頼する

フロントエンドでデコードして「ログイン済み」と判断するコードは危険です。必ずバックエンドで署名検証を行いましょう。

❌ 失敗例 3: 有効期限（exp）を無視

exp（Expiration Time）が切れたトークンを受け入れると、古いトークンが悪用されるリスクがあります。検証時に必ずexpもチェックしましょう。

❌ 失敗例 4: alg: none を許可

署名なしトークン（alg: none）を許可すると、誰でも偽トークンを作れてしまいます。実運用では必ず署名アルゴリズムを指定しましょう。

6. セキュリティ・注意点（安全な運用のために）

✅ 短寿命トークンを使う

有効期限は15 分〜1 時間程度に設定し、定期的にリフレッシュする設計が推奨されます。

✅ 秘密鍵を厳重に管理

HS256（共通鍵）の秘密鍵や、RS256（公開鍵暗号）の秘密鍵が漏れると、偽トークンが作られてしまいます。環境変数や専用の鍵管理サービス（AWS KMS、Google Cloud KMS など）を活用しましょう。

✅ HTTPS で通信

JWT は平文で送られるため、必ず HTTPSで通信してください。HTTP 通信では盗聴のリスクがあります。

✅ XSS 対策

トークンを localStorage に保存すると、XSS 攻撃で盗まれる危険があります。可能であればHttpOnly Cookieに保存し、JavaScript からアクセスできないようにしましょう。

7. 手を動かす：ツールで試してみよう

理論だけでなく、実際に JWT をデコードしてみましょう。

📌 JWT Decoder を使う

  1. サンプルトークンをコピー（上記の例、または実際のトークン）
  2. /tools/jwt-decoder にアクセス
  3. トークンを貼り付けると、Header・Payload・Signature が即座に表示されます

試してみること:

  • Payload のexp（有効期限）を確認
  • Header のalg（署名アルゴリズム）を確認
  • 改ざんしたトークンをデコードしてみる（デコードは成功するが、検証は失敗することを確認）

注意: このツールはデコード専用です。署名検証は行いません。検証は必ずバックエンドで実装しましょう。

8. 3 分クイズ：理解度チェック

次の問いに答えてみましょう（答えは記事中にあります）：

  1. JWT の 3 つの部分は何？
  2. デコードと検証の違いは？
  3. Payload に入れてはいけない情報の例を挙げてください
  4. alg: none を許可すると何が問題？
  5. 有効期限（exp）が切れたトークンを受け入れるとどうなる？
答えを見る
  1. Header・Payload・Signature
  2. デコードは「中身を読む」だけ。検証は「改ざんされていないか確かめる」
  3. パスワード、クレジットカード番号、個人情報など
  4. 誰でも偽トークンを作れてしまう
  5. 古いトークンが悪用されるリスクがある

9. 関連リンク

JWT は「自己完結型の認証トークン」として広く使われていますが、デコード ≠ 検証 を理解し、安全に運用することが重要です。

覚えておきたいポイント:

  • Payload は平文（機密情報は入れない）
  • 検証は必ずバックエンドで
  • 短寿命トークン + リフレッシュトークンの併用
  • HTTPS 通信・XSS 対策は必須

関連ツール:

参考リンク:

さあ、JWT Decoder でトークンをデコードして、実際の構造を確かめてみましょう！

関連ツール: /tools/jwt-decoder