JWTエンコーダー（生成・署名）
ヘッダーとペイロードのJSONから、HS256・HS384・HS512のいずれかでHMAC署名したJWT（JSON Web Token）をその場で生成できる開発者向けツールです。秘密鍵を含め、入力内容は一切サーバーへ送信せずブラウザ内だけで処理を完結します。
対応するHMAC署名アルゴリズム一覧
| アルゴリズム | ハッシュ関数 | 署名長 | 説明 |
|---|---|---|---|
| HS256 | SHA-256 | 256ビット（32バイト） | 最も広く使われるデフォルトのHMAC署名。OAuth 2.0・OpenID ConnectのIDトークンなど多くの実装で標準採用されている。 |
| HS384 | SHA-384 | 384ビット（48バイト） | HS256よりも長い署名でセキュリティマージンを高めたい場合に使用する中間的な選択肢。 |
| HS512 | SHA-512 | 512ビット（64バイト） | 最も長い署名長を持ち、十分に長いランダムなシークレットと組み合わせて使うことが多い。 |
JWTを生成して署名する
このツールはヘッダーとペイロードのJSONから、HS256・HS384・HS512のいずれかでHMAC署名したJWTをその場で組み立てます。秘密鍵を含め、入力はすべてブラウザ内だけで処理され、サーバーへ送られることはありません。
**ここで最も誤解されやすいのが、署名は改ざんを検知するための仕組みであって、暗号化ではないという点です。** JWTのヘッダーとペイロードは Base64URL でエンコードされているだけなので、**トークンを手にした人は誰でも中身をそのまま読めます。** パスワードや個人情報をペイロードに入れてはいけないのはこのためです。もう一つの要点が鍵の性質で、HS系は**署名する側と検証する側が同じ秘密鍵を共有する**方式です。検証を他所へ任せたい場合は、秘密鍵を渡さずに済む RS256 や ES256 のような公開鍵方式を選ぶことになります。
生成の手順
- ヘッダーのJSONを入力する `{"alg":"HS256","typ":"JWT"}` の形です。選んだアルゴリズムと揃えてください。
- ペイロードのJSONを入力する `sub`・`iat`・`exp` など必要なクレームを書きます。**秘密にしたい値は入れないでください。**
- 署名アルゴリズムを選ぶ HS256・HS384・HS512 から選べます。数字はハッシュのビット長です。
- 秘密鍵を入力してトークンを得る 3つの部分がドットで連結された文字列が生成されます。
使いこなすためのヒント
- 生成したJWTはブラウザ内のWeb Crypto APIのみで署名され、シークレットを含む入力内容は toolbase.cc のサーバーには一切送信されません。
- 署名アルゴリズム（HS256/HS384/HS512）を切り替えると、ヘッダーJSON内の
algフィールドが自動的に書き換わります。kidなど他のクレームを追加したい場合はヘッダーを直接編集してください。 - このツールはHMAC（共通鍵）方式のみに対応しています。RS256・ES256のような公開鍵方式の署名が必要な場合は、Node.jsなどサーバーサイドのライブラリを利用してください。
- ヘッダー・ペイロードを編集した後は、必ず「JWTを生成する」を再度押してください。押すまでは編集前の内容で生成された古いJWTが表示されたままになります。
- 生成したJWTの中身をその場で確認したい場合は、姉妹ツールの JWTデコーダー に貼り付けるとヘッダー・ペイロードを検証できます。
活用シーン
APIの動作確認をする
**任意のクレームを持つトークンをすぐ作れるため、認可の分岐を手早く試せます。**
有効期限の扱いを検証する
`exp` を過去の時刻にしたトークンを作り、期限切れが正しく弾かれるかを確認できます。
テスト用のトークンを用意する
自動テストのフィクスチャとして、決まった内容のトークンを用意できます。
JWTの構造を学ぶ
入力を変えながら生成すると、どの部分がトークンのどこに現れるかが目で追えます。
JWTの用語
- ヘッダー
- アルゴリズムと種別を示す最初の部分です。`alg` と `typ` を持ちます。
- ペイロード
- クレームを収めた2つ目の部分です。**Base64URL で符号化されているだけで、暗号化はされていません。**
- 署名
- 3つ目の部分で、ヘッダーとペイロードから鍵を使って算出します。**改ざんを検知するためのもので、内容を隠す働きはありません。**
- クレーム
- ペイロードに入る各項目です。`sub`（主体）・`iat`（発行時刻）・`exp`（有効期限）などが標準で定められています。
- HMAC
- 共通鍵を使うメッセージ認証の方式です。**署名する側と検証する側が同じ鍵を持つ必要があります。**
- Base64URL
- URLに含められるよう記号を置き換えた Base64 です。`+` と `/` を `-` と `_` に替え、末尾の詰め物を省きます。
よくある質問
alg フィールドの値が食い違うと、生成したJWTを他の実装で検証した際にエラーになる場合があるため、両者は必ず一致させてください。
余談ですが ― なぜJWTの署名は「ブラウザだけ」で完結できるのか
JWTの署名アルゴリズムは、送信側と受信側が同じ秘密鍵を共有する「共通鍵方式（HMAC、HS256/HS384/HS512）」と、秘密鍵で署名し公開鍵で検証する「公開鍵暗号方式（RS256・ES256等）」に大きく分かれます。前者はW3Cが標準化したWeb Crypto API（SubtleCrypto）のcrypto.subtle.sign()を使えば外部ライブラリなしでブラウザだけで完結して計算できるため、このツールでは意図的にHMAC方式のみに対応を絞っています。
HMAC署名の安全性は、ヘッダーやペイロードの内容ではなく秘密鍵の推測されにくさにすべて依存します。RFC 7518（JSON Web Algorithms）はHS256であれば256ビット（32バイト）以上の鍵長を推奨しており、短い単語や辞書に載っているような文字列を秘密鍵に使うと、総当たり攻撃で署名を偽造されるリスクがあります。実運用では乱数生成器で作った十分に長いランダム文字列を秘密鍵として使うべきです。
このツールはAPI開発時の動作確認や、Webhookの署名検証ロジックをテストする用途を想定した開発者向けのユーティリティです。入力したシークレットはブラウザ内のメモリ上でのみ扱われ外部送信はされませんが、共有端末やブラウザ拡張機能がクリップボードや入力内容を収集するリスクはゼロではありません。本番環境で実際に使用している秘密鍵は、動作確認目的であってもこの種のツールには入力しないことを強く推奨します。