無料JWTジェネレーター
カスタムヘッダーとペイロードでJSON Web Tokenを作成します。ブラウザ内でHMAC-SHA256で署名されます · データはデバイスから送信されません。
生成されたトークン
JWT とは実際何か
JSON Web Token (JWT)(「ジョット」と発音)は、二者間で転送するクレームをコンパクトかつURLセーフに表現する形式です。形式はピリオドで区切られた3つの Base64url エンコードセグメントで構成されます: ヘッダー.ペイロード.署名。ヘッダーはトークンの種類(常に JWT)と署名アルゴリズム(よく使われるのは HS256、RS256、ES256)を宣言します。ペイロードはクレーム、つまり iss(発行者)、sub(主体)、aud(対象)、exp(Unix タイムスタンプの有効期限)、nbf(これより前は無効)、iat(発行時刻)、jti(JWT 識別子)などの標準フィールドと、発行者が含めたい任意のアプリケーション固有クレームを持つ JSON オブジェクトを運びます。署名はヘッダーとペイロードが改変されていないことの暗号学的証明で、ヘッダーで宣言されたアルゴリズムと鍵で連結文字列 base64url(ヘッダー).base64url(ペイロード) に署名して生成されます。JWT は2015年5月の RFC 7519 で Michael B. Jones、John Bradley、Nat Sakimura によって仕様化され、JOSE(JSON Object Signing and Encryption、RFC 7515 〜 7520)の以前の作業を基盤としています。この形式は現代のWeb認証で支配的なトークン形式となり、OAuth 2.0 / OIDC の実装、API ゲートウェイ、SPA のセッショントークン、マイクロサービス間認証、大規模なクッキーセッション管理で利用されています。
署名アルゴリズムの選択、HS256 vs RS256 vs ES256
JWT は JOSE アルゴリズムレジストリ(RFC 7518)に登録された複数の署名アルゴリズムをサポートします。HS256(HMAC-SHA256)は最もシンプルです。同じ秘密鍵で署名と検証を行う対称アルゴリズムです。計算コストが低く、実装が容易で、署名者と検証者が同じ当事者である場合(例: 自己発行のセッショントークンを使うアプリ)に適しています。RS256(RSA-SHA256)は非対称です。秘密鍵で署名し、公開鍵で検証します。発行者と検証者が異なる当事者の場合に使われます。Auth0、Okta、Google Identity Platform、Microsoft Entra ID、その他のクラウドアイデンティティプロバイダーのほとんどは RS256 で署名された JWT を発行します。クライアントは秘密を共有せずに公開された JWKS(JSON Web Key Set)エンドポイント経由で署名を検証できるからです。ES256(ECDSA P-256 SHA-256)は RS256 の楕円曲線版で、同じ公開鍵/秘密鍵モデル、はるかに短い鍵(256ビット、対する RSA は最低 2048ビット)、より高速な検証を提供します。EdDSA(Ed25519)は ES256 の現代的な後継で、わずかに高速で暗号学的特性がよりクリーンです。最近の JWT ライブラリでサポートされていますが、まだ普遍的ではありません。none は JWT 仕様で許可された「署名なし」モードで、実装が alg: none トークンを拒否し損ねたときに複数のライブラリでセキュリティインシデントを引き起こしました。教訓は、JWT 検証者はアルゴリズムが期待値と一致することを明示的に確認しなければならないということです。このジェネレーターは HS256 を使います。鍵生成ではなく共有秘密のみを必要とするからです。非対称アルゴリズムを本番で使う場合は、サーバー側ライブラリが正しいツールです。
JWT を手作業で生成する必要がある場合
- API エンドポイントのテスト。 API が Authorization ヘッダーに JWT を要求する場合、curl、Postman、HTTPie で手作業でテストするにはトークンが必要です。正しい形のテスト JWT を生成し、API の共有秘密(開発環境で)で署名し、その結果を使います。
- トークン関連バグの再現。 ユーザーが認証問題を報告します。彼らが受け取るはずだったトークンをそのクレームで再構築し、署名を調べ、既知の正しいトークンと既知の悪いトークンに対してサービスの検証ロジックを確認します。
- 認証プロバイダーなしのローカル開発。 JWT 認証を期待する API に向けてフロントエンドを構築していますが、まだ本番のアイデンティティプロバイダーへのアクセスがありません。開発用に現実的なクレームを持つテスト JWT を生成します。
- JWT 形式を学ぶ。 JWT をデコードし、クレームを変更し、再署名し、アプリケーションの動作を見ます。いじって学ぶこのループは、ほとんどの開発者が JWT 構造を理解する方法です。
- 内部のサービス間トークン。 二つの内部マイクロサービスが秘密を共有し、リクエスト認証に JWT を使います。共有秘密の HS256 モデルがここでは適しています。このツールはテスト目的で手作業によりトークンを生成できます。
セキュリティの落とし穴、JWT が脱線するところ
JWT には、本物のセキュリティインシデントを生み出した実装ミスの長い歴史があります。「alg: none」攻撃: 初期の JWT ライブラリはアルゴリズムフィールドを「none」(署名なし)にしたトークンを受け入れ、攻撃者が任意のトークンを偽造できるようにしました。検証者は期待されるアルゴリズムを明示的に強制しなければなりません。アルゴリズム混乱: RS256 と HS256 の両方を受け入れる検証者は、RSA 公開鍵を HMAC 秘密鍵として使うことで騙される可能性があります。攻撃者は公開鍵を使って HS256 で署名し、検証者は同じ公開鍵で HMAC として(誤って)検証します。検証者は期待されるアルゴリズムを固定しなければなりません。ペイロード内の機微データ: JWT クレームは Base64 でエンコードされていますが、暗号化されていません。トークンを保持する者は誰でもすべてのクレームを読めます。パスワード、完全なクレジットカード番号、その他の秘密をペイロードに入れてはいけません。有効期限なし: exp クレームのない JWT は永遠に有効です。常に妥当な有効期限を設定してください(アクセストークンには数分、リフレッシュトークンには数日)。失効なし: JWT は自己完結的で、いったん発行されると exp まで有効です。ユーザーがログアウトしようと、パスワードを変更しようと、アカウントが停止されようと関係ありません。この制限を受け入れるか、失効リストを維持するか(これはステートレストークンの利点を部分的に打ち消します)、ローテーションされるリフレッシュトークンと組み合わせた短命のアクセストークンを使います。localStorage と Cookie の保存: localStorage の JWT はページの任意の JavaScript からアクセス可能(XSS リスク)、HttpOnly クッキーの JWT はそうではない(ただしクロスオリジンリクエストとともに自動送信されるため CSRF リスクあり)。両方にトレードオフがあります。現代のベストプラクティスは SameSite 制限と CSRF トークンを組み合わせた HttpOnly クッキーに傾いています。
JWT vs セッションクッキー vs PASETO
JWT が唯一の選択ではありません。従来のセッションクッキーは不透明なセッション識別子を保存します。サーバーは実際のセッション状態をデータベースまたはキャッシュに保持します。利点: 失効が容易(サーバー側のレコードを削除するだけ)、クレームデータ漏洩のリスクなし、署名の複雑さなし。欠点: リクエストごとにセッションストアの参照が必要(レイテンシ)、サービス間でのスケーリングが困難。PASETO(Platform-Agnostic Security Tokens、Scott Arciszewski 2018)はアルゴリズム混乱や「none」の落とし穴を回避するように設計された JWT の代替です。バージョン管理された形式、アルゴリズムネゴシエーションなし、必須の署名、制限された暗号選択肢。PASETO はセキュリティに敏感な文脈で足場を築きましたが、より広いエコシステムで JWT を置き換えてはいません。マカロン(Google、2014)はチェーン可能な能力制限を持つより柔軟なトークン形式ですが、2026年でも基本的に研究対象にとどまっています。OAuth 2.1は OAuth 2.0 のベストプラクティスを統合します。JWT は依然として典型的なアクセストークン形式です。2026 年の実用的な選択は依然として、ステートレスマイクロサービスと API トークンには JWT、従来のサーバーレンダリング Web アプリケーションには不透明なセッションクッキー、より強力なデフォルトを求める新しいグリーンフィールドプロジェクトには PASETO です。
よくある質問
秘密キーなしでJWTをデコードできますか？
はい。JWTのヘッダーとペイロードセクションはBase64urlエンコードされているだけで、暗号化されてはいません。秘密キーなしですべてのクレームを読み取れます。秘密キーは署名が有効であること（つまりトークンが改ざんされていないこと）を検証するのにのみ必要です。
本番のJWTをここに貼り付けても安全ですか？
はい。このツールは完全にブラウザ内で動作します, データはサーバーに送信されません。トークンと秘密キーはローカルJavaScript環境でのみ処理され、ログに記録されたり送信されたりすることはありません。
HS256、RS256、ES256の違いは何ですか？
HS256は共有HMAC秘密キーを使用します（対称）。RS256とES256は公開鍵/秘密鍵ペアを使用します（非対称）, 秘密鍵でトークンに署名し、公開鍵で検証します。このツールはHMACアルゴリズムをサポートします。RS256/ES256の検証にはサーバーサイドのライブラリを使用してください。