JWT 署名検証入門：デコード ≠ 検証を 5 分で理解

1. 導入

「JWT のデコードだけで安全だと思っていた…」「署名検証の手順が分からず期限切れトークンを使ってしまった」そんな悩みはありませんか？ この記事では、JWT の署名検証の基本と、よくある落とし穴・対策を短時間で解説します。 まずは関連ツール「JWT Decoder」で実際に検証してみましょう。

2. 基本の構造

JWT は Header・Payload・Signature の 3 部構成です。alg は署名アルゴリズム、kid は鍵識別子。 Payload の exp（有効期限）, nbf（not before）, iat（発行時刻）は検証・運用で重要です。

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

• デコードは誰でもできる（Base64URL デコード）。検証は正しい鍵（共有鍵/公開鍵/JWKS）で署名の整合を確認する必要がある。
• exp/nbf/iat の意味：期限切れ・未到来・時刻の健全性を判断。サーバ側時刻差（clock drift）を考慮して leeway を設定する場合がある。

4. 手を動かす：/tools/jwt-decoder の Verify

• 検証タブを開き、期待アルゴリズムを選択。
  • HS256: 共有シークレットを入力。
  • RS256: 公開鍵(PEM)を入力。kid がある場合は JWKS を有効化して URL を指定。取得した鍵から該当 kid を自動選択。
• exp/nbf/iat のバッジを確認。期限切れや未到来の場合はエラー/警告。
• leeway秒 を適切に設定し、境界時刻の誤検知を減らす。

5. よくある失敗

• デコードだけで信頼してしまう。alg:none を許してしまう。長寿命トークンを発行して漏えい時の被害が長期化。

6. セキュリティ運用

• 短寿命＋ローテーション、鍵管理（KMS 等）、HTTPS、XSS 対策（HttpOnly/SameSite/CSP）。
• フロントでは「可視化」。真正性判断は原則サーバで行い、最小限の情報だけをクライアントへ。

7. 3 分クイズ

• デコードと検証の違いは？
• なぜ alg:none が危険？
• exp を見落とすと何が起きる？

8. 関連リンク

• RFC 7519 / jwt.io / OIDC 関連資料

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