🪪 JWT 生成・署名ツール
ヘッダー・ペイロード・シークレットを入力すると、ブラウザ内で署名済み JWT を生成します。HS256 / HS384 / HS512 対応。Web Crypto API 使用。
⚠️ セキュリティに関する注意
• シークレットは Web Crypto API でブラウザ内のみ使用され、サーバーには一切送信されません。
• 本番環境のシークレットを Web ツールに入力するのは推奨されません。テスト・学習・デバッグ用途にお使いください。
• HS256 のシークレットは最低でも 256 ビット (32 バイト)、HS512 は 512 ビット (64 バイト) 以上を推奨します。
🔗 関連ツール
📖 つまずきやすいポイント
ヘッダー・ペイロード・シークレットを入力すると、Web Crypto API を使ってブラウザ内で署名済み JWT を生成します (HS256 / HS384 / HS512)。iat や exp はボタンで追加できます。シークレットがサーバーに送られることはありません。ただし JWT について最初に理解しておくべきことがあります — JWT は暗号化ではありません。ペイロードは Base64URL で「符号化」されているだけで、鍵を持たない誰でも中身を読めます。署名が保証するのは「改ざんされていないこと」だけで、「見られていないこと」は一切保証しません。
| ケース | 何が起きるか | どうする |
|---|---|---|
| 本番のシークレットをブラウザツールに入れてしまう | このページは値をサーバーに送りませんが、「送信されない」と「痕跡が残らない」は別です。入力した文字列は DOM の中に存在し、ブラウザの入力履歴やオートフィルに残る可能性があり、スクリーンショットや画面共有に写り、インストールしている拡張機能からはページの内容が読めます。クリップボードにコピーすれば、クリップボード履歴ツールにも残ります。そして最も見落とされがちなのが生成したトークンそのもので、デバッグのために Slack やチケットに貼った JWT は、シークレットが漏れていなくても、そのトークンが有効な間ずっと使えます — JWT は Bearer トークンなので、持っている人が本人として扱われます。 | このページには使い捨てのシークレットだけを入れてください。 「ランダム生成」ボタンで作った値で十分です — 署名の仕組みを確かめるのが目的なら、本物である必要はありません。すでに本番のシークレットを貼ってしまったなら、対処は 1 つだけです: 直ちにローテーションしてください。「たぶん大丈夫」で放置すると、漏洩したかどうかを後から判定する手段がありません — HMAC のシークレットは、1 つのトークンを捕まえれば手元で総当たりできるので、辞書に載っている語や短い文字列は特に危険です。そして本番のシークレットは、そもそも人間が目にしない設計にしてください — 環境変数やシークレット管理サービスから直接読み込ませ、コピー&ペーストの経路を作らないことが最も効果的です。 |
exp は検証側でしか効かない |
exp はただのフィールドで、時間が来ればトークンが自動的に無効になる仕組みではありません — 検証する側がその値を読んで拒否して、はじめて期限として機能します。ここから 4 つの定番の不具合が出ます。(1) exp を入れ忘れると、そのトークンは永久に有効です。(2) 値の単位を間違える — JWT の時刻は「エポックからの秒数」で、JavaScript の Date.now() はミリ秒なので、そのまま入れると5 万年後を指します。(3) サーバー間の時計のずれで、発行直後のトークンが nbf にかかって拒否されます。(4) 発行済みトークンは取り消せません — ログアウトしても、パスワードを変えても、exp まで有効です。 |
アクセストークンの exp は短くしてください — 15 分から 1 時間が一般的な目安です。長期のログイン状態はリフレッシュトークンで維持し、そちらはサーバー側に保存して個別に無効化できるようにします。「取り消せない」問題を正面から解くには、これしかありません。即時の失効が要件なら、jti (トークン ID) を入れて拒否リストを持ちます — ただしその時点で「サーバーに状態を持たない」という JWT の利点は失われるので、本当にその要件があるのかを先に確かめてください。検証側の実装では、exp と nbf の比較に数十秒の許容差 (leeway) を入れます。そして時刻の単位は必ず秒 — JavaScript なら Math.floor(Date.now() / 1000) です。 |
検証側がトークンの alg を信じてしまう |
ヘッダーの alg は、攻撃者が書き換えられる場所にあります — それを読んで検証方法を決めるライブラリは、攻撃者に検証方法を選ばせていることになります。有名な破り方が 2 つあります。(1) alg: none — 「署名なし」という値を書き込み、署名部分を空にすると、素直に実装されたライブラリはこれを受け入れてしまいます。(2) RS256 と HS256 の取り違え — 本来 RSA 公開鍵で検証するはずのトークンを、alg を HS256 に書き換えて「公開鍵を HMAC のシークレットとして」署名する手口です。公開鍵は公開されているので、攻撃者は自由に有効なトークンを作れます。どちらも実装のバグであって、JWT 自体の欠陥ではありません。 |
検証側では、使うアルゴリズムを固定値として渡してください。 ほとんどのライブラリは algorithms: ['HS256'] のような引数を受け取ります — これを省略できる API なら、省略しないでください。トークンから読んだ alg は、検証の入力ではなく検証の対象です。鍵も同様に固定し、複数の鍵をローテーションするなら kid で選ぶ形にして、必ず自分の鍵集合の中から選ばせてください。シークレットの強度も忘れずに: HS256 なら 256 ビット (32 バイト) 以上のランダム値を使い、覚えられるパスワードは使わないでください — HMAC は 1 つのトークンさえあればオフラインで検証し放題なので、辞書攻撃が現実的な脅威になります。そして最後に、ライブラリを自作しないことです。 |
ペイロードに機密を入れないでください。繰り返しになりますが誰でも読めます — メールアドレス・電話番号・権限の内訳・内部の ID などを入れると、それはトークンを見た人全員に公開されます。ブラウザの DevTools を開けば自分のトークンの中身が読めることを、設計時に思い出してください。クレームは最小限にし、詳細は必要になったときにサーバーから引くのが安全です。そもそも JWT が最適でない場面も多くあります — 同一ドメインの一般的な Web アプリなら、サーバー側セッションのほうが単純で、しかも即座にログアウトできます。JWT が本当に効くのは、複数のサービスをまたぐ認証や、検証側が発行元に問い合わせられない構成です。「モダンだから JWT」は理由になりません — 状態を持たない代わりに取り消せない、というトレードオフを引き受けられるかどうかで選んでください。
📖 使い方
-
1
アルゴリズムとペイロードを設定HS256 / HS384 / HS512 からアルゴリズムを選択し、Payload フィールドに JSON クレームを入力します。+iat や +exp ボタンで標準クレームをワンクリックで追加できます。
-
2
シークレットを入力または生成シークレット欄にキーを入力するか、「ランダム生成」ボタンで 256 bit の安全な鍵を自動生成します。UTF-8 / Base64 / Base64URL の入力形式を選択できます。
-
3
生成された JWT をコピー右パネルに署名済み JWT が即座に表示されます。コピーボタンでクリップボードに取得し、JWT デコーダーや API テストに使用してください。
❓ よくある質問
HS256・HS384・HS512 の違いは何ですか?
本番環境のシークレットを入力しても安全ですか?
RS256 や ES256 などの非対称アルゴリズムには対応していますか?
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。