JWTジェネレーター：ブラウザでJWTトークンを生成・署名する

認証フローを実装していてテスト用トークンが必要。APIドキュメントにJWTのサンプルを載せたい。バックエンドが正しいクレームを受け入れるかどうかを検証したい。JWTジェネレーターを使えば、サーバーを立ち上げることなく署名済みトークンをすぐに生成できます。

JWTトークンを生成する →

JWTとは何か

JSON Web Token（JWT）は、RFC 7519で定義されたコンパクトなURL安全文字列です。当事者間で検証可能なクレームを伝達します。

すべてのJWTはドットで区切られた3つのパートで構成されます：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxMzQ1Njc4OX0.xK8vP2mQ4nR7sT1uVwXyZa3bCdEfGhIjKlMnOpQrStU

ヘッダー（第1部）：アルゴリズムとトークンタイプ
ペイロード（第2部）：クレーム（データ本体）
署名（第3部）：シークレットを使ったヘッダー + ペイロードのHMAC

各パートはBase64URLエンコードされています。署名がトークンの検証を可能にします——シークレットを持っている人なら誰でも、トークンが改ざんされていないことを確認できます。

JWTジェネレーターの使い方

JWTジェネレーターを開く
署名アルゴリズムを選択（HS256、HS384、HS512）
ペイロードJSONにクレームを入力
シークレットキーを入力
結果から生成されたトークンをコピー

アルゴリズムを変更するとヘッダーが自動で更新されます。編集するたびにトークンがリアルタイムで再生成されます。

HMACアルゴリズムの比較

ツールがサポートする3つのアルゴリズムはいずれも対称鍵方式——同じシークレットで署名と検証を行います。

アルゴリズム	ハッシュ	署名長	用途
HS256	SHA-256	256ビット	デフォルト。ほぼすべてのユースケースに適切。
HS384	SHA-384	384ビット	余分なセキュリティマージン、トークンがやや大きくなる。
HS512	SHA-512	512ビット	HMAC最強。64バイト以上のシークレットと組み合わせて使用。

ほとんどのアプリケーションではHS256が正しい選択です。 HS256とHS512のセキュリティマージンの差は実際には無視できる程度です——どちらも暗号学的に強力とみなされています。コンプライアンス要件でHS512が義務付けられている場合にのみHS512を使用してください。

よく使われるJWTクレーム

ペイロードは任意のキーを持つJSONオブジェクトです。標準登録クレーム（すべてオプション）：

クレーム	名前	説明
`iss`	発行者	トークンを発行した主体
`sub`	サブジェクト	トークンの主体（ユーザーIDなど）
`aud`	オーディエンス	トークンを受け入れるべき主体
`exp`	有効期限	トークンが失効するUnixタイムスタンプ
`nbf`	有効開始日時	これ以前はトークンが無効なUnixタイムスタンプ
`iat`	発行日時	トークンが作成されたUnixタイムスタンプ
`jti`	JWT ID	一意のトークン識別子（失効のため）

典型的な認証ペイロード：

{
  "sub": "user_123",
  "iss": "https://api.example.com",
  "aud": "https://app.example.com",
  "role": "admin",
  "iat": 1713456789,
  "exp": 1713460389
}

role、email、permissionsなどのカスタムクレームを自由に追加できます。

JWTジェネレーターの使用ケース

ローカル開発

最も一般的な用途。バックエンドがJWTを検証するが、ログインフローを毎回通らずにAPIエンドポイントをテストするためのトークンが必要な場合：

# 生成したトークンをcurlで使用
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...." \
  https://api.localhost:8000/admin/users

APIドキュメント

READMEやAPIドキュメント内の生成済みトークンは、有効なトークンがどのように見えるかを正確に示します。読者はクレーム構造をすぐに理解できます。

インテグレーションテスト

特定のクレームを持つトークンを自動テスト用に作成：

# バックエンドが正しいクレームを受け入れるかを検証
def test_admin_endpoint_requires_admin_role():
    # userロールのトークン — 拒否されるべき
    user_token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
    response = client.get('/admin/settings', headers={
        'Authorization': f'Bearer {user_token}'
    })
    assert response.status_code == 403

学習とデバッグ

JWTの仕組みを理解するには実際のバイト列を見ることが重要です。ジェネレーターは以下を示してくれます：

ヘッダーJSONがどのようにBase64URL文字列にマッピングされるか
クレームがペイロードセグメントにどのように現れるか
シークレットを変更すると署名セグメント全体がどのように変わるか

Base64シークレットオプション

一部のIDプロバイダーはBase64またはBase64URL形式でエンコードされたシークレットを提供します。シークレットがc2VjcmV0a2V5のように見える場合（secretkeyではなく）、Base64オプションを有効にしてください。ツールは署名前にデコードし、正しい署名を生成します。

生成したトークンの検証

生成したトークンが有効かどうかを確認するには、同じシークレットとアルゴリズムとともにトークンをJWTデコーダーに貼り付けてください。デコーダーはデコードされたヘッダーとペイロードを表示し、署名が有効であることを確認します。

セキュリティ：クライアントサイド署名が重要な理由

zerotool.devのJWTジェネレーターは、すべての署名操作にブラウザ組み込みのWeb Crypto API（SubtleCrypto）を使用します。ヘッダー、ペイロード、シークレットキーはブラウザの外に出ることはありません。

DevTools → Networkタブを開いてトークンを生成すると確認できます。アウトバウンドリクエストは一切発生しません。プロダクションシークレットには、クライアントサイド生成が唯一の安全な選択肢です。