JWT エンコーダー
クレームからトークンを組み立て、本当に署名する · このタブ内で動作し、どこにも送信されません
ヘッダー
ペイロード
署名鍵
鍵は使われたあと破棄されます。このブラウザーに保存されず、どこにも送信されません。
署名鍵はあなたのシステムが受け入れるトークンを作れます。本番の鍵なら自分の環境で。
HS256
署名済みトークン
署名済みトークンがここに表示されます。作成のために何もアップロードされません。署名はこのブラウザーが計算します。
JWT エンコーダー のしくみ
base64 の見せかけではなく、実際に署名されたトークンを作る JWT エンコーダーです。ヘッダーとペイロードを JSON で書き、アルゴリズムを選び、HS 系なら共有シークレットを、RS・PS・ES 系なら PKCS#8 の秘密鍵を貼り付けると、署名はブラウザー自身の WebCrypto が計算します。有効期限・発行時刻・「〜以降有効」はプリセットから打刻できるので、エポック秒を手で換算する必要はもうありません。
ヘッダーとペイロードを JSON で書き、アルゴリズムを選ぶと、入力しながらトークンが組み立てられ、署名されます。有効期限のプリセットは iat、exp、必要なら nbf を同じ一瞬から打刻するので、三つが 1 秒ずれることはありません。これは他システムのクロックずれ許容範囲の中でしか表面化しない、厄介な種類の不具合です。
alg はヘッダーに何が書かれていても、常に選んだアルゴリズムから書き込まれます。これは利便性のためではありません。あるアルゴリズムを名乗るヘッダーに別のアルゴリズムで作った署名を組み合わせたものは、JWT で最もよく知られた脆弱性の出発点であり、そのために作れなくなる正当なトークンは存在しません。ヘッダーのそれ以外のフィールドは、書いたとおりそのまま保たれます。
ハッシュより短い HS シークレットは既定で拒否されます。RFC 7518 は HS256 に 32 バイト、HS384 に 48 バイト、HS512 に 64 バイトを要求しており、ブラウザーは 4 文字でも平然と署名しますが、その結果はオフラインで数秒のうちに破られます。この検査は切ることもできます。弱いトークンを再現すること自体が目的の場合があるからです。
署名鍵は、デコーダーが検証鍵を扱うのと同じように、いやそれ以上に慎重に扱われます。localStorage に書かれず、再読み込みでも復元されず、アナリティクスのイベントにも入らず、受け取りうるバックエンドも存在しません。署名鍵は JWT を使うシステムで最も危険な秘密です。本番の鍵については、自分の環境でトークンを発行するほうが良い習慣であり続けます。
よくある質問
このエンコーダーに署名鍵を貼り付けても安全ですか。
鍵は自分のタブの中だけで使われ、そのまま破棄されます。ストレージに保存されず、アナリティクスのイベントにも入らず、受け取りうるバックエンドも存在しません。とはいえ署名鍵は JWT を使うシステムで最も危険な秘密です。持っている者はあなたのサービスが受け入れるトークンを作れてしまいます。本番の鍵については自分の環境でトークンを発行するほうが良い習慣で、このツールは開発・テスト・学習のためのものです。
どのアルゴリズムで署名できますか。
共有シークレットを使う HS256・HS384・HS512 と、秘密鍵を使う RS256/384/512、PS256/384/512、ES256/384/512 です。鍵は PKCS#8 の PEM ブロックか秘密 JWK で渡します。`alg: none` の非セキュアなトークンも作れますが、何も証明しないものとして明示されます。自分の検証側がそれをきちんと拒否するか試すには、実物が必要だからです。
なぜ短いシークレットが拒否されるのですか。
RFC 7518 は HMAC 鍵をハッシュ長以上にすることを求めています。HS256 なら 32 バイト、HS384 なら 48 バイト、HS512 なら 64 バイトです。ブラウザーは 4 文字でも平然と署名しますが、できたトークンはオフラインで数秒のうちに破られます。エンコーダーは既定でこれを止めつつ、上書きも許します。弱いトークンの再現がまさに目的である場合があるからです。
ヘッダーに書いたアルゴリズムは上書きされますか。
はい、`alg` は常に選択したアルゴリズムから書き込まれます。これは意図的です。あるアルゴリズムを名乗るヘッダーに別のアルゴリズムの署名を組み合わせたものはトークンではなく、JWT で最もよく知られた脆弱性の出発点です。`kid` や `cty` を含め、それ以外のヘッダー項目は書いたとおりに保たれます。