JWT 署名・検証ツール

自分の鍵でトークンに署名し、シークレット、PEM、JWK、ライブの JWKS に対して検証し、自分の API が公開する鍵セットを構築します。暗号処理はすべてブラウザ内で行われます。

JWT の信頼性は、その署名の信頼性に等しいと言えます。トークンは誰でも読めます——デコードだけでは何も証明されません——だからこのツールは、デコーダーができない部分を行います。自分の鍵でトークンに署名し（HS256/384/512、RS256/384/512、ES256/384/512、EdDSA）、シークレット、PEM または JWK の公開鍵、貼り付けた JWKS、kid 照合付きのライブ JWKS URL に対して検証し、自分の API が公開する JWKS を構築します。関連ガイドJWT の署名と検証では、デコードが検証ではない理由、アルゴリズム混同攻撃の仕組み、そして「検証済み」が証明すること——そして証明しないこと——を説明しています。鍵なしでトークンを読みたい場合は JWT デコーダーを、鍵そのものについては生成と変換を扱う SSH Key Suite をどうぞ。

最終更新:

トークンに署名する

🔒 署名と検証は WebCrypto を使ってローカルで行われます。シークレットと秘密鍵は送信されず、保存も記録もされません。ページを再読み込みすれば消えます。

あなたの鍵がこのページを離れることはありません

署名と検証には、貼り付けた鍵またはここで生成した鍵を使い、ブラウザの WebCrypto を使います。シークレットと秘密鍵はページのメモリ内にのみ存在します。アップロードされず、localStorage や Cookie に書かれず、URL に載ることもありません。ページを再読み込みするか閉じれば消えます。唯一の例外は、自分で開始する JWKS URL の取得です。送られるのは入力した URL のみで、公開鍵を取得するためのものです——シークレットが送られることは決してありません。本番の鍵をどこかに貼り付ける前に、JWT の署名と検証を読んでください。

正直な限界

EdDSA には現行のブラウザが必要です。WebCrypto の Ed25519 は古いブラウザにはなく、このページは署名をでっち上げる代わりに、その旨をはっきり伝えます。どこでも動く代替手段として ECDSA P-256 が用意されています。

暗号化された PEM（パスフレーズでロックされた秘密鍵）はバージョン1では未対応です。ページはそれを公然と拒否します——先に openssl pkcs8 -topk8 -nocrypt で復号してください。パスフレーズをウェブページに貼ることは決してしないでください。

JWKS URL の取得は、そのサーバーが CORS ヘッダーを送るかどうかに依存します。多くの ID プロバイダーは送りますが、送らない場合、取得は正直に失敗し、ページは JWKS を貼り付けるよう伝えます。取得されるのは公開鍵だけです——JWKS URL がシークレットを運ぶことは決してありません。

署名がデコードに勝る場面

JWT をデコードするとは、読むことです。ヘッダーとペイロードは base64url であり、トークンを持つ者なら誰でも両方を見ることができます。だからこそ、デコーダーだけでは本当に重要な唯一の問いに答えられません——発行者は本当に署名したのか、という問いです。署名はその仕事のもう半分です。秘密鍵（または HMAC シークレット）を持つ者が署名を作り、検証は公開鍵を使って同じ計算をやり直します。このページは両方の半分をブラウザ内に置きます。扱う鍵は、ウェブツールが扱う入力の中で最も機微なものだからです。

この区別は非対称アルゴリズムで最も重要になります。HS256 では、検証するシークレットと署名するシークレットが同じです——検証できる者は誰でもトークンを発行できます。1つのサービスの中では問題ありませんが、それ以外では漏洩です。RS256、ES256、EdDSA では、署名鍵は発行者の手元に残り、公開鍵だけが旅をします。API は JWKS を公開し、新しい kid を追加して鍵をローテーションし、世界中のすべての検証者に、偽造する力を持たせることなくトークンを確認させることができます。

このツールが拒否すること

2つの拒否は意図的です。1つ目は alg: none です。署名が不要だと主張するトークンは、理由を表示したうえで全面的に拒否されます——それを受け入れる検証者は偽造を受け入れることになります。2つ目はアルゴリズムの混同です。HMAC シークレットで提示された RS256 トークン（またはその逆）は、明示的な警告とともに失敗します。鍵を別のファミリーとして静かに再解釈することは決してありません。どちらも古典的な JWT 攻撃であり、ここでは構造的に防がれています——鍵のファミリーはトークンの alg のファミリーと一致しなければならず、一致しなければ検証は失敗します。

3つ目の拒否はもっと微妙です。このページはトークンが「信頼できる」と決して言いません。有効な署名が証明するのは、トークンが鍵で署名されたことと、有効期限内にあること——それだけです。その鍵を信頼するかどうかは、鍵の出所についての判断です。ID プロバイダーの well-known URL から取得した JWKS、自分で固定した公開鍵、自分で生成したシークレット。ガイドJWT の署名と検証では、「検証済み」が証明することと証明しないことを順を追って説明しています。

JWT の用語を正確に

JWT. JSON Web Token（RFC 7519）：当事者間でクレームを運ぶための、コンパクトで URL セーフな方法——ヘッダー.ペイロード.署名で、それぞれ base64url エンコードされています。ペイロードは誰でも読めます。シークレットに依存するのは署名だけです。

JWS. JSON Web Signature（RFC 7515）：JWT の下にある署名形式です。JWT とは、ペイロードが JSON のクレームセットである JWS のことです。

JWK. JSON Web Key（RFC 7517）：1つの暗号鍵を表す JSON オブジェクト——kty と、鍵素材（RSA の n/e、EC の x/y、Ed25519 の x、共有シークレットの k）です。

JWKS. JSON Web Key Set： "keys" 配列を持つオブジェクト——発行者が公開鍵を公開する標準的な方法で、通常は /.well-known/jwks.json に置かれます。

kid. キー ID：どの鍵がトークンに署名したかを示すヘッダークレームです。検証者は JWKS と照合します。kid がない場合、セットに鍵が1つだけならそれが使われ、その旨がページに表示されます。

alg. 署名アルゴリズムを名指すヘッダークレーム（HS256、RS256、ES256、EdDSA など）。検証者は受け入れるアルゴリズムを固定しなければなりません——トークン自身の alg クレームを信頼することが、混同攻撃です。

HMAC. Hash-based Message Authentication Code：対称署名——同じシークレットで署名と検証を行います。高速でシンプルですが、シークレットを持つ者は誰でもトークンを発行できます。

RSASSA-PKCS1-v1_5. RS256/384/512 の背後にある RSA 署名方式です。ハッシュをラップし、秘密指数で累乗します。決定的です——同じ入力からは常に同じ署名バイトが得られます。

EdDSA. Edwards-curve Digital Signature Algorithm：ここでは Ed25519——鍵が小さく、検証が高速で、署名は決定的です。WebCrypto でのサポートには現行のブラウザが必要です。

よくある質問

秘密鍵をこのページに貼り付けても安全ですか？

このページでは、鍵がブラウザを離れることはありません。署名は WebCrypto を使ってページのメモリ内で行われ、何もアップロード、保存、記録されず、再読み込みで消えます。危険なのはサーバー側の署名ツールで、秘密鍵がネットワークを渡ります。ローカルであっても、信頼できるデバイスを使ってください——そして、共有マシンで本番の鍵を貼り付けた場合は、漏洩したものとして扱ってください。テスト用の鍵はここで生成するのが最善です。

RS256 トークンがシークレットで検証できないのはなぜですか？

シークレットと RSA 鍵は別のファミリーだからであり、ページは両者を混ぜることを拒否します——その拒否こそがアルゴリズム混同への防御です。RS256 トークンには発行者の RSA 公開鍵（PEM、JWK、JWKS）が必要です。シークレットで検証できるのは HS256/384/512 だけです。公開鍵を間違った形式で持っている場合は変換してください。JWKS タブで PEM ⇄ JWK の変換ができます。

JWKS URL の取得では実際には何が送信されますか？

入力した URL への、JSON を求める GET リクエストが1回だけです。鍵、シークレット、トークン、識別子は一切同行しません——返ってくるのは公開鍵のセットです。サーバーが CORS ヘッダーを送らなければ、ブラウザが読み取りをブロックし、ページは JWKS を貼り付けるよう伝えます。

ここでは検証できるのに、API がトークンを拒否します。なぜですか？

ここでの検証は、提示された鍵に対する署名と時間枠を確認します。API はクレームも確認します。期待する発行者（iss）、対象とするオーディエンス（aud）、現在信頼しているキー ID（kid）です。ローテーションで外れた鍵で署名されたトークンや、別のオーディエンス向けに発行されたトークンは、数学的には検証できても拒否されます——正しく。

EdDSA がブラウザで動きません。どうすればよいですか？

Ed25519 には現行のブラウザが必要です——古いブラウザには WebCrypto の Ed25519 がまったくなく、このページはでっち上げる代わりにその旨を伝えます。代替手段として ES256（ECDSA P-256）を使ってください。WebCrypto が存在する場所ならどこでも対応しており、鍵はこのページで生成できます。Ed25519 をどうしても使う場合は、ブラウザを更新してください。