JWT 生成器
JSON Web Tokenを作成、HeaderとPayloadをカスタマイズ
JWTとは？
JWT (JSON Web Token) は、当事者間で安全に情報を送信するためのオープン標準 (RFC 7519) です。JWTは3つの部分で構成され、ドットで区切られます：Header（ヘッダー）、Payload（ペイロード）、Signature（署名）。JWTは認証と情報交換シーンで広く使用されています。 セキュリティに関わる結果は単独で判断せず、鍵、文脈、アルゴリズム、信頼できる取得元を合わせて確認する必要があります。
使い方
JWT生成フロー
- 署名アルゴリズムを選択してください（デフォルトはHS256）
- 署名シークレットを入力するか「生成」をクリックしてください
- Payload JSONを編集し、クイック追加ボタンで標準クレームを追加できます
- issued at（iat）と有効期限（exp）の時刻を設定してください
- 「JWT Token生成」ボタンをクリックしてください
- 生成されたTokenをコピーしてテストや開発に利用できます
トークンのセキュリティ
- HMACアルゴリズムでは強力なシークレットを使用し、RSA/ECDSAアルゴリズムでは秘密鍵を適切に保護してください。
- 現実的なexp、iat、issuer、audienceクレームを設定してください。構文的に正しいJWTでも安全でなかったり、サービスに拒否される可能性があります。
利用シーン
仕組み
JWT のジェネレーターとパーサーは逆方向の処理です：パーサーは 3 つの部分に分割し、ジェネレーターはそれらを組み立てます。中核は Signature セグメントの計算です。 組み立てフロー：1) Header JSON を構築、例 {"alg":"HS256","typ":"JWT"}；2) 標準クレームとプライベートクレームを含む Payload JSON を構築；3) Header と Payload をそれぞれ Base64URL でエンコードし、h_b64 と p_b64 を得る；4) h_b64 と p_b64 をピリオドで結合し input = h_b64 + '.' + p_b64 とする；5) alg に応じて署名を計算：HMAC-SHA256/384/512(secret, input)；6) 署名結果を Base64URL でエンコード；7) 最終トークンは input + '.' + sig_b64。 HMAC-SHA256 署名：secret を鍵として（推奨 32 バイト以上）input に HMAC を適用します。内部では SHA-256 を 2 ラウンド実行：secret から ipad/opad を導出し、SHA256(secret XOR ipad || msg) XOR opad を計算します。 鍵強度：secret の長さが安全性を決めます。RFC 7518 は HS256 の鍵を 256 ビット（32 バイト）以上と規定しています。本番環境では暗号論的に安全な乱数源（例：crypto.randomBytes）を必ず使い、「secret」「password」「123456」のような文字列は使わないでください。 よくある落とし穴：1) alg すり替え攻撃：サーバーは alg を厳密に検証し、トークンのヘッダーから alg を読み取って対応するアルゴリズムにディスパッチしてはいけません；2) 弱い鍵：短すぎる secret は総当たりされます；3) ペイロード改ざん：HMAC が完全性を保証するため、攻撃者がペイロードを書き換えるとサーバー側の検証が失敗します；4) トークン漏洩：JWT は失効できないため、流出したら exp まで待つしかありません。 本ツールの範囲：HS256/HS384/HS512 のみを生成します。RS256（RSA）や ES256（ECDSA）などの非対称アルゴリズムは発行者側で秘密鍵を保管する必要があり、バックエンドの署名サービスや専用 SDK が担当します。本ページでは生成しません。
- HMAC-SHA256署名コア：HMAC(secret, header_b64 + '.' + payload_b64)で256ビットの署名を出力し、Base64URLエンコードします。
- HS256のキー長は>= 32バイト（256ビット）が必要です。crypto.getRandomValuesまたはcrypto.randomBytesでの生成を推奨し、短いキーは辞書攻撃に対して脆弱です。
- 本ツールは HMAC 系列の署名（HS256/HS384/HS512）のみを生成します。RS256 や ES256 などの非対称アルゴリズムは発行者側で秘密鍵を保管する必要があり、本ツールでは生成しません——この種のトークンが必要な場合はバックエンドの署名サービスや専用 SDK を利用してください。
- iat/exp/nbfはすべてUnixタイムスタンプ（秒単位、ミリ秒ではありません）。サーバーは通常exp > now()、nbf <= now()、iat <= now()を要求します。
- alg=none攻撃：許可されたアルゴリズムのホワイトリストをサーバー側で維持し（例：['HS256']）、トークンヘッダーからアルゴリズムを動的に選択しないでください。多くのJWTライブラリは歴史的にデフォルトでalg=noneを許可しており、これは既知の脆弱性です。
- JWTは発行すると失効できません。唯一の手段はexpを待つことです。能動的な失効にはjtiブラックリストを維持するか、短命のアクセストークンとリフレッシュトークンの組み合わせを使用してください。
使用例
基本的な HS256 の例
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","name":"Alice","role":"admin","iat":1705312800,"exp":1705399200}
Secret: my-super-secret-key-32-bytes-long
Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNTMxMjgwMCwiZXhwIjoxNzA1Mzk5MjAwfQ.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4Uiat と exp による独自の有効期限
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"iss":"https://auth.example.com","sub":"user-456","aud":"api.example.com","iat":1705312800,"exp":1705316400}
Secret: another-strong-secret-32-bytes-long
ヘッダーとペイロードを Base64URL でエンコードし、ドットで結合した文字列に共有 secret を使って HMAC-SHA256 を適用します。Token 欄には Authorization ヘッダーへそのまま貼り付け可能な 3 セグメントの最終文字列が表示されます。カスタムクレーム
Header: {"alg":"HS256","typ":"JWT"}
Payload: {
"sub": "user-789",
"name": "Bob",
"role": "editor",
"tenant": "acme-corp",
"permissions": ["read:docs", "write:docs"],
"scope": "docs.read docs.write",
"iat": 1705312800,
"exp": 1705399200,
"jti": "550e8400-e29b-41d4-a716-446655440000"
}よくある質問
JWT はローカルで生成されますか？
はい。ヘッダー、ペイロード、署名は Web Crypto API を使用してブラウザ内で計算されます。署名用の秘密鍵や秘密鍵がページから出ることはありません。ただしトークン自体は実サービスに貼り付ければログに残ったり露出したりするデータとして扱ってください。
どの署名アルゴリズムがサポートされていますか？
本ツールは HS256/HS384/HS512（共有シークレットによる HMAC）を生成します。RS256/RS384/RS512（RSA）や ES256/ES384/ES512（ECDSA）などの非対称アルゴリズムは本ツールでは生成しません——検証側がそれらを要求する場合はバックエンドの署名サービスや専用 SDK を使用してください。本番では alg=none を避けてください。まともな検証実装は未署名トークンを拒否します。
ペイロードには何を入れますか？
sub、iss、aud、exp、iat、nbf などの標準クレームに加え、サービスで使用するカスタムクレームを入れます。ペイロードは小さく保ちましょう。JWT はヘッダーで送られ、リクエストごとに肥大化します。パスワード、完全なクレジットカード番号、その他の秘密情報は決して入れないでください。ペイロードは Base64URL であって暗号化されていません。
有効期限はどう設定しますか？
exp に、トークンが有効でなくなるべき Unix タイムスタンプ (ミリ秒ではなく秒) を設定します。exp なしのトークンは技術的には合法ですが、ほとんどの本番サービスは必須としています。一般的な値はアクセストークンで 5〜60 分、リフレッシュトークンで 7〜30 日です。
生成した JWT が検証に失敗するのはなぜですか？
よくある原因は、ヘッダーの alg が検証側の期待と一致しない、秘密鍵/鍵が異なる、ペイロードクレーム (iss、aud) がサーバー設定と一致しない、発行者と検証側のクロックスキューが許容範囲 (通常 ±60 秒) を超えている、手動編集で Base64URL エンコーディングが壊れた (改行を入れないこと) などです。
私の秘密鍵はサーバーに送信されますか？
いいえ。署名は完全に Web Crypto を使用してブラウザ内で行われます。とはいえ、本番の署名鍵をどんな Web ツールにも決して貼り付けないでください。本番外の鍵でテストし、その後実際のバックエンドで署名してください。
HS256 と RS256 のどちらを使うべきですか？
HS256 は両者で秘密鍵を共有する必要があるため、同じサービスがトークンを発行・検証する状況にしか向きません。RS256 (または ES256) は発行者が秘密鍵を保持し、各消費者が公開鍵で検証できるようにします。OAuth/OIDC やマルチサービスアーキテクチャには適切な選択肢です。 本ツールは HS 系のトークンのみを生成します。RS256/ES256 が必要な場合はバックエンドの署名サービスや専用 SDK を使用してください。