無料 JWT シークレット生成ツール — HS256/384/512

JWT シークレット生成ツールとは？

// The secret you generate here goes straight into your signing code.
// Node.js with jsonwebtoken — the JWT_SECRET env var holds the key.
import jwt from 'jsonwebtoken';

const secret = process.env.JWT_SECRET; // e.g. base64url value from this tool

// Sign a token with HS256 (HMAC-SHA-256).
const token = jwt.sign({ sub: 'user-42', role: 'member' }, secret, {
  algorithm: 'HS256',
  expiresIn: '15m'
});

// Verify it — pin the algorithm to a whitelist; never trust the token's alg.
const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });

// ---------------------------------------------------------------
// Python with PyJWT — same secret, same algorithm pinning.
// import jwt
// token = jwt.encode({"sub": "user-42"}, key, algorithm="HS256")
// payload = jwt.decode(token, key, algorithms=["HS256"])  # whitelist!

// ---------------------------------------------------------------
// Equivalent-strength CLI generation (32 bytes for HS256):
//   openssl rand -base64 32
//   node -e "console.log(require('crypto').randomBytes(32).toString('base64url'))"
//   python -c "import secrets; print(secrets.token_urlsafe(32))"

主な機能

実践例

Algorithm: HS256 · Format: base64url

3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Algorithm: HS512 · Format: base64url

k2Lp9XqA0mNbVcZ7rT4wYsHfGjUe8RoIdPlNkBvM3xQ1aWtCyZuS6FhEgJ (86 chars)

Click "Copy for .env"

JWT_SECRET=3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Show the CLI command

openssl rand -base64 32

Toggle the eye icon

•••••••••••••••••••••••••••••••••••••••••••  ↔  3sJ9aFq2kP7m…

JWT シークレット生成ツールの使い方

1. 1

   署名アルゴリズムを選ぶ

   HS256・HS384・HS512 を選択します。本ツールはその HMAC 種別に対して RFC 7518 §3.2 の最小鍵長（32・48・64 バイト）を即座に適用するので、数値を調べたり鍵が短くなりすぎたりする心配はありません。

2. 2

   出力形式を選ぶ

   base64url が既定で、JWT のネイティブな URL セーフ・パディングなしの符号化です。ローダーが要求するなら標準 base64 に、0〜f の文字しか受け付けないシステムなら hex に切り替えます。3 つとも同じランダムバイトを同一のエントロピーで符号化します。

3. 3

   シークレットを表示してコピーする

   シークレットは既定でマスクされ、デモや画面共有の最中に画面に出ないようになっています。目のアイコンをクリックして表示し、Copy で生の値を取得するか、Copy for .env で .env ファイルや CI 変数用の JWT_SECRET=… 行をコピーします。

4. 4

   必要に応じて再生成する

   Regenerate をクリックすると、crypto.getRandomValues から引き出した新しく独立したシークレットが得られます。環境ごとに 1 つ生成してください。同じ署名鍵を開発・ステージング・本番で再利用してはいけません。

5. 5

   CLI の同等手段を使うか、署名へ進む

   CLI パネルには、スクリプトでのプロビジョニング用に対応する openssl・Node・Python のワンライナーが表示されます。シークレットが手に入ったら、JWT エンコーダーでトークンに署名し、JWT デコーダーで署名を確認してください。

よくある JWT シークレットの間違い

JWT_SECRET=mySuperSecret123  →  low entropy, brute-forceable

JWT_SECRET=3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0  →  32 random bytes

16-byte key with HS256  →  below the 32-byte minimum

32-byte key with HS256  →  meets RFC 7518 §3.2

Math.random()-based key  →  predictable, unsafe

crypto.getRandomValues key  →  full entropy

Service A: raw string · Service B: base64-decoded  →  signatures never match

Both services use the identical stored string  →  signatures verify

Same JWT_SECRET in dev, staging, prod  →  one leak breaks all

A unique secret per environment  →  blast radius contained

jwt.verify(token, secret)  →  accepts the token's alg

jwt.verify(token, secret, { algorithms: ['HS256'] })  →  pinned

このツールを使う人

新しいサービス用に JWT_SECRET を用意する

HMAC 署名のトークンを発行する API を立ち上げますか？ ライブラリが使うアルゴリズムを選び、シークレットを JWT_SECRET=… 行としてコピーして、サービスの環境に入れてください。開発・ステージング・本番には別々の鍵を生成し、1 つのシークレットを複数の環境で共有しないでください。

侵害された、または古くなったシークレットをローテーションする

鍵の漏洩が疑われたり、単にローテーションの時期が来たりしたら、ここで新しいシークレットを生成し、新しい kid を割り当て、有効なトークンが期限切れになるまで検証し続けられる重複期間を設けて展開してください。侵害が確定した場合は、即座にローテーションし、受け入れ集合から古い鍵を外します。

弱い、または手入力した鍵を置き換える

JWT_SECRET が短いフレーズやコピーされた例の値になっているコードベースを引き継ぎましたか？ その鍵はオフラインで総当たり可能です。完全なエントロピーの 32 バイトの代替を生成し、ローテーション期間を設けて差し替え、悪用される前にトークン偽造の穴を塞いでください。

パイプラインで鍵生成をスクリプト化する

鍵を手作業ではなく CI や Dockerfile で作成したいですか？ CLI パネルの openssl・Node・Python のワンライナーを使ってプロビジョニングスクリプト内で同等の強度のシークレットを生成し、各コマンドが生成するバイト長と符号化を理解するためにこのページを使ってください。

JWT 署名を安全に教える

本番の鍵を一切露出させずに HS256 の仕組みをチームに説明できます。画面上で使い捨てのシークレットを生成し（表示するまでマスクされたまま）、JWT エンコーダーでサンプルトークンに署名し、JWT デコーダーで検証して、署名と検証の一連の流れを見せられます。

HS256・HS384・HS512 の鍵サイズを比較する

どの HMAC 種別で標準化するか迷っていますか？ アルゴリズムを切り替えて、必要な鍵長と符号化された文字列がどう伸びるか（43・64・86 文字の base64url）を確認し、設定にコミットする前に、システムに合う強度とトークンサイズのトレードオフを選んでください。

ローカル開発用の鍵を生成する

ローカルの認証フローを動かすために、手早く有効なシークレットが必要ですか？ ワンクリックで生成し、.env 用にコピーすれば作業を再開できます。デプロイ前に置き換え忘れるプレースホルダーではなく、本物の CSPRNG の鍵で。

生成ツールの仕組み

crypto.getRandomValues（CSPRNG）

シークレットは、Web Crypto の暗号学的に安全な擬似乱数生成器である crypto.getRandomValues で Uint8Array を埋めることで生成されます。これは Web Crypto 鍵生成を支えるのと同じエントロピー源です。Math.random はどこでも決して使いません。統計的に予測可能で、いかなる暗号鍵にも不適切だからです。

RFC 7518 §3.2 の鍵サイズ調整

アルゴリズムごとのバイト数は、HMAC 鍵がハッシュ出力以上のサイズであることを求める JSON Web Algorithms の要件に従います。HS256（SHA-256）は 32 バイト、HS384（SHA-384）は 48、HS512（SHA-512）は 64 です。アルゴリズムを選ぶと最小値が設定され、本ツールは仕様の下限を下回る鍵を出力しません。

RFC 4648 符号化（base64url / base64 / hex）

生のバイトは RFC 4648 のアルファベットで符号化されます。base64url はパディングなしの URL セーフなアルファベットを使い（32 バイト → 43 文字）、標準 base64 は +、/、= パディングを使い（→ 44 文字）、hex は 1 バイトを 2 文字で書きます（→ 64 文字）。形式を切り替えると同じバイトが再符号化され、根底のエントロピーは変わりません。

なぜ base64url が既定なのか

JWT の構成要素自体が base64url で符号化されており、URL セーフ・パディングなしのアルファベットは、base64url のシークレットがヘッダー・URL・設定ファイル内でエスケープを必要としないことを意味します。標準 base64 の + や / や末尾の = はそうした文脈で壊れる可能性があるので、base64url が JWT_SECRET の保守的な既定です。

Copy-for-.env のフォーマット

Copy for .env は、dotenv 形式のローダーが変更なしに解析する形である、引用符なしの 1 行 JWT_SECRET= を出力します。生のシークレットには .env ファイルで引用が必要になる文字が含まれないので、その行はそのまま貼り付けても安全です。

同等の強度の CLI コマンド、バイト単位では同一でない

CLI パネルの openssl rand -base64 N、Node randomBytes(N).toString('base64url')、Python secrets.token_urlsafe(N) のコマンドはすべて、選んだアルゴリズムに対して N バイトの安全なランダムバイトを引き出します。これらは同等の強度の鍵を生成しますが、同じ文字列ではありません。openssl はパディング付きの標準 base64 を出力するので、本ツールの base64url 既定とはアルファベットや末尾の文字が異なります。

JWT シークレットのベストプラクティス

鍵長をアルゴリズムに合わせる

RFC 7518 §3.2 が要求するとおり、HS256 には最低 32 バイト、HS384 には 48、HS512 には 64 を使ってください。本ツールが代わりに行いますが、もし手で鍵のサイズを決めるなら、ハッシュ出力長を決して下回らないこと。短すぎる HMAC 鍵は署名を弱め、厳格なライブラリに拒否される可能性があります。

常に CSPRNG で生成し、パスワードは使わない

JWT シークレットは誰も覚える必要のないマシン認証情報なので、エントロピーを惜しまず、パスフレーズ・辞書語・手入力した文字列ではなく暗号学的に安全なランダム鍵を使ってください。人間が選んだシークレットは、JWT クラッキングツールが自動化するオフライン総当たり攻撃の最も狙いやすい標的です。

環境ごとに固有のシークレットを使う

開発・ステージング・本番にはそれぞれ独自の JWT_SECRET を持たせるべきです。1 つの鍵を共有すると、低リスクの環境での漏洩がどこでもトークンを偽造でき、ローテーションが全か無かになります。環境ごとに別々のシークレットをここで生成し、それぞれを独自のシークレットマネージャースコープに保存してください。

検証時にアルゴリズムを固定する

検証側では、常に明示的なアルゴリズムのホワイトリスト（jsonwebtoken では algorithms: ['HS256']、PyJWT では algorithms=["HS256"]）を渡し、トークン内の alg フィールドを決して信用しないでください。トークンが自己申告するアルゴリズムを受け入れると、シークレットがどれほど強力でも、古典的な alg 混同や alg:none の偽造攻撃が成立します。

kid ヘッダーと重複する鍵でローテーションする

署名したトークンに鍵識別子（kid）を付け、有効な鍵を JWKS エンドポイントで公開して、ダウンタイムなしにローテーションできるようにしてください。新しい鍵で新しいトークンに署名しつつ、古い鍵のトークンが期限切れになるまで古い鍵も受け入れます。侵害が疑われる場合は重複期間を省き、古い鍵を即座に失効させます。

よくある質問