このツールを使って本番用のJWTを作成できますか?

技術的には可能ですが、おそらくすべきではありません。ツールは完全にブラウザで動作し、サーバーにデータを送信しないので、セキュリティモデルは健全です。本当の懸念は運用面です。本番システムでは、JWT署名はサーバーサイドで行い、シークレットは適切なシークレットマネージャーに保管され、ブラウザコンテキストには決して公開されないようにすべきです。このツールはテスト、ローカル開発での認証モック、デバッグに使ってください。本物の処理はバックエンドに任せましょう。

このツールにシークレットを入力するのは安全ですか?

はい — ツールはクライアントサイドのみで、シークレットはどこにも送信されません。Web Crypto APIを使ってブラウザ内で完全に処理されます。とはいえ、ここでは本番のシークレットではなくテスト用のシークレットを使うべきです。技術的なリスクが低くても、シークレットがどこに現れるかについて良い習慣を実践することは重要です。本番のシークレットがブラウザタブに現れたら、それは修正に値するプロセスの問題です。

HS256とRS256の違いは何ですか?

HS256 (HMAC-SHA256) はトークンの署名と検証の両方に1つの共有シークレットを使います。トークンを検証できる側はトークンを作成することもできます。同じ鍵を共有しているからです。RS256は秘密鍵/公開鍵のペアを使います。秘密鍵がトークンに署名し (サーバーサイドのみ)、公開鍵が検証します (自由に配布できます)。RS256は、トークンを発行できないがサービスでトークンを検証したいマルチサービスアーキテクチャに適しています。

同じペイロードでもJWTが毎回違って見えるのはなぜですか?

ペイロードに `iat` (issued-at) を含めていて現在のタイムスタンプで自動入力されている場合、タイムスタンプが変わるためトークンも生成のたびに変わります。テスト用に再現可能なトークンが欲しい場合は、`iat` クレームを削除するか固定値にハードコードしてください。トークン構造自体は決定的です。同じペイロード、同じシークレット、同じヘッダーは常に同じ結果を生成します。

ここで生成されたJWTをAuth0、Firebase、その他の認証プロバイダーで使えますか?

直接は使えません。Auth0、Firebase Auth、Cognitoなどのサービスは、独自の秘密鍵で署名されたJWTを発行し、独自の公開鍵に対してトークンを検証します。外部で生成されたトークンをそれらのシステムに注入することはできません。このツールが本当に役立つのは自分のミドルウェアのテストです。たとえば、Express.jsやFastAPIのJWT検証ロジックがエッジケースを正しく処理することを、自分が制御するトークンを使って検証できます。

オンラインJWTエンコーダー: 何もインストールせずにトークンを作成・署名する

すべての開発者は、ほぼ同じ瞬間にJWTが何かを学びます。初めて認証を実装する必要があり、誰かがそれを提案する時です。RFCを読み、base64でデコードされたペイロードを見て「なるほど、これはただのJSONだ」と思います。そして次の1時間、署名の部分が正確に何をしているのか、なぜしているのかについて混乱して過ごします。

その混乱は理解できます。JWTは構造はシンプルですが、セキュリティ上の含意は微妙です。このガイドでは実用的な側面に焦点を当てます。テストとデバッグのためにJWTを作成して使うために実際に知っておく必要があること、そしてToolBox HubsのJWTエンコーダーでライブラリのインストールやサーバーの起動なしにそれを行う方法です。

JWTとは実際に何か

JSON Web Tokenは、ドットで結合された3つのbase64urlエンコードされた文字列です: header.payload.signature。

ヘッダー はトークンタイプと署名アルゴリズムを識別します。

{
  "alg": "HS256",
  "typ": "JWT"
}

ペイロード にはクレーム、つまり情報のキーバリューペアが含まれます。

{
  "sub": "user_12345",
  "email": "alice@example.com",
  "role": "admin",
  "iat": 1714000000,
  "exp": 1714086400
}

シグネチャ は、シークレットキーを使って作成された、エンコードされたヘッダーとペイロードの暗号学的ハッシュです。これがトークンを改ざん検知可能にします。ペイロードの1文字を変更すると、シグネチャが一致しなくなります。

多くの人がつまずくポイントがここです。ペイロードは暗号化されていません。base64urlエンコードされているだけで、トークンを持っている人は誰でもすぐにデコードして読むことができます。シグネチャはトークンが改ざんされていないことを証明しますが、内容を隠すことは何もしません。これは何を入れるかを決める上で非常に重要です。

実際に使うクレーム

JWT仕様は「登録済みクレーム」をいくつか定義しています。これらは標準的な意味を持つフィールド名で、ライブラリが自動的に検証する方法を知っています。

sub (subject) — トークンが誰についてのものか。通常はユーザーIDまたはアカウント識別子。安定していて一意であるべきです。よくある間違い: 不透明なIDの代わりにメールアドレスを置くこと。メールアドレスは変わりますが、不透明なIDは変わりません。

iat (issued at) — トークンが作成された時のUnixタイムスタンプ。デバッグに便利で、一部の検証ロジックは遠い未来から来たように見えるトークンを拒否するためにこれをチェックします (クロックスキュー攻撃)。

exp (expiration) — トークンが拒否されるべきUnixタイムスタンプ。これは重要です。有効期限のないJWTは永遠に有効で、つまり漏洩した場合、シークレット全体をローテートする以外に手段がありません。短期セッションでは15〜60分が一般的です。リフレッシュトークンでは数時間から数日。常にこれを設定してください。

iss (issuer) — トークンを発行したのが誰かを識別する文字列。マルチサービス環境で、正しいソースからのトークンを検証していることを確認するのに便利です。検証ミドルウェアは iss が期待値と一致することをチェックし、それ以外を拒否できます。

aud (audience) — トークンが誰を対象にしているか。サービスA向けに発行されたトークンがサービスBに対して使われるのを防ぎます。多くの場合、API識別子またはトークンを受け入れるべきサービスのリストです。

カスタムクレームは問題なく一般的です。アプリがリクエストごとのデータベースルックアップを避けるためにトークンに role、plan、org_id、または他のコンテキストを埋め込む必要がある場合は、それらも追加してください。ただし覚えておいてください: 誰でも読めます。

オンラインJWTエンコーダーを実際に使う場面

正直な答えは、本番用ではないということです。本番では認証サーバーが署名を処理します。シークレットはサーバー環境を離れず、トークンはログインフローの一部としてプログラム的に生成されます。

オンラインエンコーダーが本当に役立つのは次のような場面です。

認証サーバーを動かさずに認証ミドルウェアをテスト。 JWTを検証するバックエンドエンドポイントを構築していて、手動でテストしたい。Postmanやcurlに貼り付ける既知のシークレットで署名された有効なトークンが必要。オンラインエンコーダーで数秒で得られます。

ローカル開発での認証モック。 フロントエンドが認証を必要とするAPIに対して構築されているが、認証サービスがまだローカルでセットアップされていない。正しいクレームとテストシークレットでトークンを生成し、開発環境にハードコードして先に進みます。これを出荷するわけではなく、ローカル開発をブロック解除しているだけです。

トークン検証失敗のデバッグ。 トークンがサーバーで拒否されているが、理由が分からない。exp が過去? iss が間違っている? ペイロードが不正?エンコーダーで既知の正しいトークンを作って比較し、JWTデコーダーで悪いものを検査できます。一緒に使えばデバッグループになります。

初めてJWTの動作を理解する。 ライブラリがJWTで何をしているかを理解する最良の方法は、自分で作って何が起こるかを見ることです。有効期限を調整し、アルゴリズムを変更し、何が壊れるかを観察します。オンラインツールはコードの摩擦なしにこれを実践的にできます。

HS256署名の仕組み (数学なしで)

HS256はHMAC-SHA256の略です。HMACは、ハッシュ関数 (この場合はSHA-256) とシークレットキーを一緒に使って、メッセージ認証コードを生成する構成です。

平易な言葉でのプロセス: エンコードされたヘッダーを取り、ドットを追加し、エンコードされたペイロードを追加します。その文字列とシークレットキーをHMAC-SHA256関数に入力します。固定長のハッシュが返ります。そのハッシュをbase64urlエンコードして、トークンの3番目の部分として追加します。

なぜこれが機能するのか? HMACは、シークレットキーを知らずには特定のメッセージに対する有効なハッシュを生成できないように設計されているからです。誰かがペイロードを変更しても、シグネチャを再計算して一致させることはできません。それにはシークレットが必要です。サーバーがJWTを検証する時、受信したヘッダーとペイロードに対して同じHMAC-SHA256計算を再実行し、結果をトークン内のシグネチャと比較し、それに応じて受け入れるか拒否します。

ToolBox Hubsエンコーダーは、ブラウザ組み込みのWeb Crypto APIを使ってこの計算を行います。これはブラウザがTLSに使うのと同じ暗号プリミティブです。手書きJavaScriptや怪しいサードパーティライブラリで行っているのではありません。これは知っておく価値があります。

HS256にできないこと

HS256は対称鍵を使います。トークンに署名するシークレットが検証もします。これはトークンを検証できる人なら誰でも作成もできることを意味します。あるサーバーがトークンを発行し、別のサーバーが検証するシステムでは、両方のサーバーがシークレットを知る必要があります。サービス間でシークレットを共有することは、調整とセキュリティ表面の問題です。

RS256 (とES256) は非対称鍵を使います。秘密鍵がトークンに署名します。認証サーバーだけがこれを必要とし、そのサーバーから決して離れません。公開鍵がトークンを検証します。これは自由に配布でき、JWKSエンドポイントで公開でき、トークンを検証する必要がある任意のサービスがロードできます。サービスは発行する能力を持たずに検証できます。

単一のバックエンドサービスより複雑な何かについては、RS256が通常より良いアーキテクチャ的選択です。HS256はセットアップがより簡単で、小規模なシステムや、すべてのバリデーターを制御するシナリオには適しています。

繰り返す価値のあるセキュリティのこと

機密データをJWTに入れない。 パスワードハッシュ、クレジットカード番号、必要のないPII、どれも入れない。ペイロードはトークンを持つ誰にでも見えます。クライアント、認証ヘッダーをキャプチャするロギングシステム、間にあるプロキシやCDNを含みます。JWTペイロードはURLクエリ文字列のように扱ってください: 見えるものとして扱う。

オンラインツールではテストシークレットを使う。 ツールが本当にクライアントサイドでデータをどこにも送信しなくても、ブラウザUIに本番シークレットを入力する習慣は悪いものです。テストシークレットを作ってください。気になるなら test-secret-do-not-use-in-production をキーとして使ってください。本物のシークレットはパスワードのように扱う: それが住むサーバーから離れない。

常に有効期限を設定する。 exp のないJWTは永遠の認証情報です。漏洩したら、署名キーをローテートするまで問題があります。これは既存のすべてのトークンを無効化し、全員をログアウトさせます。短期トークン+リフレッシュトークンフローが標準パターンであるのには理由があります。

アルゴリズム混乱攻撃は本物。 一部のJWTライブラリには、alg ヘッダーを none に変更するとライブラリが署名なしトークンを受け入れるという歴史的な脆弱性がありました。サーバーが期待するアルゴリズムを常に検証し、それ以外は拒否してください。トークン自体からの alg ヘッダーを信頼しないでください。

ToolBox Hubs vs. jwt.io

jwt.ioは標準的なJWTツールで、ほとんどの開発者が知っています。良いツールです。しかし、ToolBox Hubsを好む可能性のある2つの理由があります。

第一に、ToolBox Hubsは明示的にプライバシーファーストでクライアントサイドのみです。jwt.ioは歴史的に、入力されたシークレットがログに記録される可能性があるかどうかについて精査を受けてきました。jwt.ioが悪意があるとは言いません。しかしツールのプライバシーモデルが明確に文書化されていない場合、リスク計算が変わります。私たちのツールはすべてをブラウザ内で処理します。

第二に、ToolBox Hubsは関連ツールと統合します。JWTをエンコードした後、JWTデコーダーに直接ジャンプして検査したり、値をハッシュする必要があればハッシュジェネレーターにペイロードを通したり、JWTペイロードがプレーンテキストで運ぶべきでない何かのために対称暗号化が必要ならテキスト暗号化/復号化を使えます。

とはいえ: jwt.ioには私たちにない機能があります。ライブラリ選択や鍵ペア生成を伴うRS256サポートを含みます。必要なものに合った正しいツールを使ってください。

ローカル開発のための実用的なワークフロー

開発中に私が実際にJWTエンコーダーをどう使うかを示します。

トークンに必要なクレームを決める — 通常 sub、exp、ミドルウェアがチェックする任意のアプリ固有クレーム (role や org_id など)。
exp をデバッグセッション中に期限切れにならないほど十分な未来に設定する。私は通常、現在のUnix時間プラス86400 (24時間) にします。タイムスタンプコンバーターが暗算を助けてくれます。
覚えやすいテストシークレットを入力する — dev-secret-not-real のように明らかに偽物のもの。
トークンを生成し、APIクライアント (Postman、curl、HTTPie、何でも) に貼り付ける。
検証で何かがうまくいかない時、トークンをJWTデコーダーに貼り付けてペイロードが正しく見えることを確認し、サーバーが期待するシークレットとアルゴリズムが生成に使ったものと一致するかチェックする。

このループはJWT関連のデバッグ混乱の90%を解決します。残りの10%は通常、クロックスキュー (exp がずれている) かアルゴリズムの不一致 (HS256を生成したのにライブラリがRS256を期待している) です。

ツールができないこと

限界について正直に。

RS256やES256のサポートなし。 非対称鍵署名は利用できません。秘密鍵を提供する必要があり、ブラウザUIでそれを扱うのは複雑になります。RS256のテストには、ローカルの jsonwebtoken npmパッケージや python-jose ライブラリがより適しています。

トークン失効なし。 JWTは設計上ステートレスです。発行されたら、有効期限まで有効です (シグネチャが検証される限り)。組み込みの失効はありません。期限切れ前に特定のトークンを無効化する能力が必要なら、サーバーにトークンブロックリストが必要です。エンコーダーはそれに役立ちません。これはアーキテクチャの問題です。

JWKS生成なし。 RS256ベースのシステムでは、JWKS (JSON Web Key Set) エンドポイントも必要です。これはこのツールの範囲外です。

範囲内のすべて、つまりテストとデバッグのためのHS256署名トークンの作成、JWT構造の理解、ローカル開発での認証モックについては、JWTエンコーダーが儀式なしに仕事を完了します。

はじめに

JWTエンコーダーツールを開き、{"sub": "test-user", "role": "admin"} のような単純なペイロードを入力し、テストシークレットを設定してGenerateを押してください。出力を見てください。それからJWTデコーダーに貼り付けて分解されるのを見てください。

一度それをすれば、JWT構造は抽象的でなくなります。3つの部分が何か、base64urlエンコードされたJSONがどう見えるか、シグネチャがただのハッシュであることが分かります。それ以外のすべて — ライブラリの統合、アルゴリズム選択、クレームの検証 — はその基盤の上に構築されます。

これと一緒に開いておく価値のある関連ツール: トークンを検査するためのJWTデコーダー、HMACが何を生成するかを理解するためのハッシュジェネレーター、そしてbase64エンコードされたプレーンテキストでは本当に十分でないケースのためのテキスト暗号化/復号化。