JWT HS256 署名検証 | 秘密鍵で署名一致をその場で確かめる検証ツール

貼り付けた JWT のヘッダーとペイロードを秘密鍵で HMAC-SHA-256 し、再計算した署名をトークンの 3 番目のセグメントと突き合わせる。結果は「有効」「不一致」「alg が HS256 以外」の 3 状態で表示し、header と payload は JSON に整形して並べる。

💡 このツールについて

JWT のデバッグで一番つまずくのは「トークンは読めるのに、署名が合っているか分からない」場面。デコーダー系のツールは base64url を開いて中身を見せてくれるが、署名そのものが正しいかは別問題で、秘密鍵を使った再計算が要る。

このツールは header.payload を共有秘密鍵で HMAC-SHA-256 し、base64url にエンコードした値を、トークン末尾の署名と文字列比較する。一致すれば「有効」、ずれていれば「不一致」、ヘッダーの alg が HS256 以外なら「alg 非対応」として弾く。秘密鍵を 1 文字変えたり、ペイロードを書き換えたりすると即座に不一致へ変わるので、どの値が署名を壊しているかを切り分けられる。

対象は HS256（HMAC 方式）のみ。RS256 や ES256 のような公開鍵・楕円曲線方式は秘密鍵ではなく鍵ペアで検証するため、本ツールでは扱わない。alg がそれらだった場合は「alg 非対応」と明示する。

🧐 よくある質問

Q. デコーダーと何が違う? デコーダーは header と payload を base64url から開いて表示するだけで、署名の正否は判定しない。このツールは秘密鍵で HMAC を再計算し、トークンの署名と一致するかまで確認する。

Q. 署名が「不一致」になる主な原因は? 秘密鍵の取り違え、ペイロードの改ざん、トークンのコピー時に末尾が欠けた、header.payload の区切りがずれた、のいずれか。1 つずつ戻して確かめると原因を絞れる。

Q. 秘密鍵はどの形式で入れる? HS256 の共有秘密鍵を UTF-8 文字列としてそのまま入力する。base64 でエンコードされた鍵を使っている場合は、発行側が秘密鍵として渡している文字列と同じものを入れる。

Q. 期限切れ（exp）も判定する? このツールは署名の一致だけを見る。exp や nbf などのクレーム検証は行わないので、payload の JSON を目視で確認する。

Q. alg を none にしたトークンは? alg が HS256 以外（none を含む）なら「alg 非対応」と表示する。none を受け入れる実装は脆弱性になり得るため、検証側では拒否するのが基本。

📚 豆知識

HS256 の「HS」は HMAC using SHA-256 の略で、JWT のアルゴリズム仕様（RFC 7518 / JWA §3.1）では唯一の実装必須アルゴリズムとして定められている。共有秘密鍵 1 つで署名と検証の両方を行えるため小規模なシステムで広く使われる一方、発行側と検証側が同じ鍵を持つ必要があり、鍵が漏れると誰でも有効なトークンを作れてしまう。署名は header と payload を . でつないだ「signing input」に対して計算され、トークンの 3 番目のセグメントは payload の中身そのものではなく、この signing input から導いた MAC である点が見落とされやすい。

入力した JWT と秘密鍵はブラウザの中だけで処理され、サーバーには送信されない。HMAC の計算も標準の Web Crypto API でローカルに完結する。