JWT署名検証ツール（RS256/ES256、公開鍵検証）
RS256・ES256で署名されたJWT（JSON Web Token）を、SPKI形式の公開鍵（PEM）を使ってその場で検証できる開発者向けツールです。ヘッダー・ペイロードのデコード結果と有効期限も同時に確認できます。入力内容はサーバーへ送信せずブラウザ内だけで処理します。
対応する署名アルゴリズム一覧
| アルゴリズム | 鍵の種類 | ハッシュ関数 | 説明 |
|---|---|---|---|
| RS256 | RSA（RSASSA-PKCS1-v1_5） | SHA-256 | RSA公開鍵暗号方式による署名。Google・Auth0・Oktaなど主要なOAuth 2.0/OpenID ConnectプロバイダーがIDトークンに使う標準的なデフォルトアルゴリズム。 |
| ES256 | ECDSA（P-256楕円曲線） | SHA-256 | RSAより短い鍵長・署名サイズで同等の安全性を実現できる楕円曲線暗号による署名。モバイルアプリやIoT機器などデータ量を抑えたい用途で採用が増えている。 |
公開鍵でJWTの署名を検証する
このツールは RS256・ES256 で署名されたJWTを、SPKI形式のPEM公開鍵で検証します。ヘッダーとペイロードのデコード結果、そして有効期限も同時に表示します。入力はすべてブラウザ内で処理され、外部へ送信されることはありません。
**押さえておきたいのは、「署名が正しい」ことと「トークンが有効である」ことは別だという点です。** 署名の検証が通るのは、その内容が発行後に書き換えられていないという証明にすぎません。実際の認証では、加えて `exp`（有効期限）・`nbf`（有効開始時刻）・`iss`（発行者）・`aud`（想定受信者）が自分の期待と合っているかを確かめる必要があります。**もう一つ、実装上の落とし穴として有名なのが、検証に使うアルゴリズムをトークンのヘッダー任せにしてしまうことです。** 受け入れる `alg` はサーバー側であらかじめ固定しておかないと、攻撃者に選ばせる隙を作ってしまいます。
検証の手順
- 検証したいJWTを貼り付ける ドットで区切られた3つの部分からなる文字列です。
- 公開鍵をPEM形式で貼り付ける **秘密鍵ではなく公開鍵です。** RS256はRSA、ES256はP-256楕円曲線の鍵に対応します。
- 署名を検証する 鍵と署名が合致するかどうかが判定されます。
- デコード結果と有効期限を確認する **署名が通っても期限が切れていれば使ってはいけません。** 両方を見てください。
使いこなすためのヒント
- 入力する公開鍵はPEM形式（SPKI、「-----BEGIN PUBLIC KEY-----」で始まる形式）である必要があります。秘密鍵ファイルや証明書（.crt）をそのまま貼り付けても検証できません。
- JWTのヘッダーにある
algフィールドの値（RS256かES256か）に応じて、内部で使用する検証アルゴリズムが自動的に切り替わります。手動での選択は不要です。 - 署名検証と同時にペイロードの
expクレームもチェックし、有効期限切れの場合は警告を表示します。ただし署名が正しくても期限切れなら本来は拒否すべきトークンです。 - このツールはRS256・ES256のみに対応しています。HS256のような共通鍵方式のJWTを確認したい場合は、姉妹ツールのJWTエンコーダーで同じ秘密鍵を使って再署名し、生成結果が一致するか比較する方法があります。
- 検証に使う公開鍵は秘密情報ではないため、IDプロバイダーの公開エンドポイント（JWKS等）から取得したものをそのまま貼り付けて問題ありません。
活用シーン
IDトークンの中身を確かめる
認証基盤が発行したトークンを、公開鍵と突き合わせて確認できます。
鍵の取り違えを切り分ける
**検証に失敗するとき、鍵が違うのか署名が壊れているのかを手元で分けて確かめられます。**
鍵のローテーションを検証する
新旧どちらの鍵で通るかを試し、切り替えの段取りを確かめられます。
不具合の原因を追う
認証が通らない報告を受けたとき、トークン側の問題かどうかを最初に切り分けられます。
JWT検証の用語
- RS256
- RSA鍵とSHA-256を用いる署名方式です。**署名は秘密鍵で、検証は公開鍵で行います。**
- ES256
- P-256楕円曲線とSHA-256を用いる署名方式です。RSAより鍵と署名が短く済みます。
- SPKI
- 公開鍵を収める標準の形式です。PEMでは `-----BEGIN PUBLIC KEY-----` で始まります。
- exp
- 有効期限を示すクレームです。**署名が正しくても、この時刻を過ぎたトークンは受け入れてはいけません。**
- nbf
- 有効になる時刻を示すクレームです。これより前のトークンはまだ使えません。
- alg混同攻撃
- **トークンのヘッダーが指すアルゴリズムをそのまま信じて検証してしまう実装の弱点です。** 受け入れる方式は検証側で固定します。
よくある質問
余談ですが ― HMACと公開鍵署名、何が違うのか
JWTの署名方式は大きく共通鍵方式（HMAC、HS256など）と公開鍵方式（RSA/ECDSA、RS256・ES256など）に分かれます。共通鍵方式は署名する側と検証する側が同じ秘密の文字列を共有する必要があるのに対し、公開鍵方式では署名する側だけが秘密鍵を持ち、検証する側は誰でも入手できる公開鍵だけで検証できます。この違いはAPI設計における役割分担に直結します。姉妹ツールのJWTエンコーダー（HS256）は「発行者と検証者が同じサーバー内で完結する」用途向けで、このツールが対象とするRS256・ES256は「発行者と検証者が別の組織・別のサーバーである」用途向けと言い換えられます。
実際、GoogleのOAuth 2.0やOpenID Connect、Auth0、Oktaといった主要なIDプロバイダーが発行するIDトークンは、ほぼ例外なくRS256（またはRS256をデフォルトとしつつES256を選択可能）で署名されています。これはIDプロバイダー側だけが秘密鍵で署名し、無数にあるクライアントアプリ（検証する側）は公開鍵だけを使って検証できるようにするためです。秘密鍵を全クライアントに配布する必要がないため、鍵漏洩のリスクを署名者側の1箇所に閉じ込められます。
RS256とES256はどちらもSHA-256でハッシュを取る点は共通しますが、暗号方式が異なります。RS256はRSA暗号（一般に2048ビット以上の鍵長）を使うため署名サイズが大きくなりがちですが、実装の枯れ具合と対応ライブラリの多さが強みです。ES256は楕円曲線暗号（P-256）を使い、RSAより大幅に短い鍵長・署名サイズで同等の安全性を確保できるため、モバイル環境やペイロードサイズを抑えたいAPIで採用が増えています。