JWT Verifier
認証ヘッダーとトークン情報をブラウザ内で点検します。入力はサーバーへ送信しません。期限・claim・schemeの一次切り分けに使えます。
JWKS状態
期限チェック
exp（有効期限）
iat（発行時刻）
nbf（有効開始）
状態
ブラウザ内で処理します。入力はサーバーへ送信しません。まずはここで一次切り分けしてください。
使い方
JWTを貼り付けて「検証」。algを確認し、鍵種（共有鍵/公開鍵/JWKS）を合わせて指定します。署名成功後に期限チェック結果を確認してください。
注意（このツール）
- HSは共有鍵、RS/ESは公開鍵で検証します。秘密鍵の貼り付けは推奨しません。
- 署名検証がOKでも、iss/aud/subなどの業務クレーム検証は別途必要です。
- JWKS取得はCORSに依存します。失敗時はURL可達性と許可設定を確認してください。
このページについて
何をするツール？
JWTの署名を検証し、header/payloadを整形表示します。exp/nbf/iatの期限チェックもできます。
HS/RS/ESアルゴリズムと、手動キーまたはJWKSによる検証に対応します。
「JWTが本物か（改ざんされていないか）」を確認したいときに使います。デコードだけなら JWT Decoder を使ってください。
対応アルゴリズム（HS/RS/ES）
JWTの署名方式はheaderの alg で指定されます。このツールは代表的なJWSアルゴリズム（HMAC/RSA/ECDSA）に対応します。
- HS256/384/512：共有鍵（シークレット）で検証
- RS256/384/512：RSA公開鍵（PEM/SPKI）で検証
- ES256/384/512：ECDSA公開鍵（PEM/SPKI）で検証
キーの用意（手動 / JWKS）
HS系は共有鍵（シークレット）を入力します。RS/ES系は公開鍵（PEM）を入力します（秘密鍵は不要です）。
JWKS URLを使うと、kidに一致するJWKを選んで検証できます（kidが無い場合は1本だけなら自動選択）。
JWKSの注意（CORS）
JWKSはブラウザからURLへ直接アクセスして取得します。取得できるかは相手サーバーのCORS設定に依存します。
切り分け手順（おすすめ）
- headerのalgとkidを確認する
- algに対応する鍵種（HS secret / RS/ES public key）を選ぶ
- 署名検証を通した後に exp/nbf/iat を評価する
- 失敗時は kid不一致・鍵種不一致・時刻ズレ・トークン改ざんを順に確認する
推奨（実務）
- 許可algを固定し、想定外algは拒否する
- 署名OKでも必ず iss/aud/sub などの業務クレームを検証する
- JWKSはkey rotationを前提にし、kid運用を明確化する
このツールでできること
- 署名検証（HS256/384/512, RS256/384/512, ES256/384/512）
- JWKS（kid付き）でのキー選択
- exp/nbf/iat の期限チェック（スキュー設定）
期限チェック（exp/nbf/iat）
exp/nbf/iat は通常「Unix time（秒）」です。サーバー時刻とクライアント時刻のズレがある場合は、スキュー（leeway）を設定します。
- exp：有効期限（now > exp + leeway で失効）
- nbf：有効開始（now + leeway < nbf で無効）
- iat：未来発行の検知（任意）
よくある失敗
- HS用シークレットでRSトークンを検証しようとする
- JWKS取得はできるがkid一致キーが無い
- 時刻ズレでexp/nbf判定だけ失敗する
- 署名成功で安心し、aud/iss検証を省略してしまう
注意（運用）
- 判定結果だけで信頼判定はできません。署名検証とissuer確認を必ず実施してください。
- 時刻ずれや環境設定差で再現性が変わるため、検証時刻と設定を記録してください。
参照仕様
- RFC 7519（JWT）
- RFC 7515（JWS）
- JWKS（RFC 7517）
- RFC 7518（JWA）
- RFC 8725（JWT BCP）
- Web Crypto API（ブラウザの署名検証）
FAQ
HS/RS/ES は何が違う？
HSは共有鍵（HMAC）、RS/ESは公開鍵（RSA/ECDSA）で検証します。
alg が none のJWTは？
このツールでは無効として扱います。
秘密鍵（private key）を貼る必要はありますか？
いいえ。RS/ESは公開鍵で検証できます。秘密鍵の貼り付けは避けてください。
注意（セキュリティ）
- 秘密鍵やトークンは取り扱いに注意してください（画面共有/ログ貼り付け等）。
- JWKSを使う場合はブラウザからURLへアクセスします。
- 検証がOKでも、aud/iss などのアプリ固有チェックは別途必要です。
参考リンク
症状別ケーススタディ（このページ向け）
署名検証を中心に、鍵・アルゴリズム・クレーム整合を確認するページです。
- alg が運用想定（HS/RS/ES）と一致しているか確認する
- kid と公開鍵セットの対応を確認する
- iss/aud の検証条件を満たすか確認する
実装時チェックリスト（このページ向け）
- 受け入れる alg を明示的に固定する
- 鍵ローテーション時に旧鍵期間を設ける
- 検証失敗ログに reason code を残す
- 検証と認可判定ロジックを分離する
次に見る（診断順）
site_map ルールに基づいて、次に確認すべきページを表示しています。
- JWT 401/403 切り分け手順 — Authorization / WWW-Authenticate / claims / 署名検証を連携して 401 と 403 を分離する
- JWT Decoder と Verifier の使い分け — デコード確認と署名検証の役割差を整理し、401/403 切り分け導線へつなぐ
- WWW-Authenticate Inspect — WWW-Authenticate challenge を解析
- JWT Clock Skew Check — iat/nbf/exp の時刻ズレを検出
- Authorization Inspect — Authorization ヘッダー形式を解析
- JWT TTL Check — exp/iat/nbf から有効期間と残TTLを算出
- OAuth Bearer Diagnostic — Bearer と WWW-Authenticate の整合を診断
- JWT 401/403 Troubleshooting — 401/403の認証失敗をヘッダーとJWTクレームから症状別に切り分け
同テーマの導線
認証
Bearer・WWW-Authenticate・JWT を横断して認証失敗を切り分け
- OAuth Bearer Diagnostic — Bearer と WWW-Authenticate の整合を診断
- JWT 401/403 Troubleshooting — 401/403の認証失敗をヘッダーとJWTクレームから症状別に切り分け
- JWT Claim Audit — JWTの必須/推奨クレーム不足を監査
- JWT TTL Check — exp/iat/nbf から有効期間と残TTLを算出
- JWT Clock Skew Check — iat/nbf/exp の時刻ズレを検出
- Authorization Inspect — Authorization ヘッダー形式を解析
- WWW-Authenticate Inspect — WWW-Authenticate challenge を解析
- JWT Decoder — JWTのheader/payloadを復号して整形表示
Example
eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJleHAiOjE3MDAwMDAwMDB9.signature