JWT Secret ジェネレーター

JSON Web Token が信頼できるのは署名があるからです。HS256、HS384、HS512 アルゴリズムでは、その署名は一つの共有シークレット（JWT_SECRET）を使ってヘッダーとペイロードから計算した HMAC です。ユーザーがログインするとサーバーはこれでトークンに署名し、以降のリクエストでは中のクレームを信頼する前に毎回署名を検証します。

つまりシークレットは、攻撃者と偽造トークンの間に立つ唯一の壁です。これを知る者は任意のユーザー ID、任意のロール、任意の有効期限で JWT を発行できます。したがって、ランダムであること、選んだアルゴリズムに対して十分な長さであること、サーバーだけに置くこと、そしてバージョン管理に決してコミットしないことが必須です。

RFC 7518（JSON Web Algorithms）§3.2 は、HMAC キーはハッシュ出力長以上でなければならないと定めています。短いキーは署名を弱めるだけでなく仕様違反であり、jose のような厳格なライブラリは受け付けません：

本ツールのデフォルトは 32 バイトで、ちょうど HS256 の下限です。HS512 で署名する場合は強度を 64 バイトに切り替えてください（48 バイトが必要な HS384 にも 64 バイトで問題ありません）。hex は 1 バイトあたり 2 文字なので、32 バイトのキーは 64 文字の文字列になります。

なぜ短くて人間が読めるシークレットはダメなのか？HS256 の安全性は SHA-256 ではなくシークレットのエントロピーで頭打ちになるからです。一般的な単語を組み合わせた 12 文字のパスワードのエントロピーはせいぜい 40 ビット程度。hashcat の JWT モードを走らせる GPU マシンは毎秒数十億の候補を試し、トークンを一つ傍受するだけでオフラインで復元できます。ランダムな 256 ビットのキーは総当たりの射程外です。

HS256 は対称アルゴリズムで、同じシークレットが署名と検証の両方を行います。高速でトークンは小さく、設定は環境変数一つだけ。単一のバックエンドが自分でトークンを発行し自分で消費する構成――大半の Next.js アプリやモノリスがこれに当たります――では正しい選択です。

RS256 と ES256 は非対称アルゴリズムで、秘密鍵が署名し公開鍵が検証します。API ゲートウェイ、モバイルアプリ、マイクロサービス、サードパーティなど、トークンを発行できてはならない相手に検証だけさせたい場合に使います。公開鍵は JWKS で公開でき、秘密鍵は発行者の外に出ません。

どちらを選ぶにせよ、検証側で受け入れるアルゴリズムを固定してください。トークンのヘッダーに決めさせる方式（悪名高い alg: none や RS256 → HS256 の混同攻撃）は実際のシステムを破っています。jsonwebtoken も jose もまさにこのために明示的な algorithms リストを受け取ります。

1. 生成したキーを .env ファイルに追加します：

# .env
# HS256 → 32 bytes (64 hex chars); HS512 → 64 bytes (128 hex chars)
JWT_SECRET=your-generated-secret

2. 定番の Node.js ライブラリ jsonwebtoken では、シークレットと明示したアルゴリズムで署名・検証します：

// lib/jwt.ts — jsonwebtoken (Node.js runtime)
import jwt from "jsonwebtoken";

const secret = process.env.JWT_SECRET!;

export function signToken(payload: object) {
  return jwt.sign(payload, secret, { algorithm: "HS256", expiresIn: "1h" });
}

export function verifyToken(token: string) {
  // Always pin the algorithm list — never let the token pick it.
  return jwt.verify(token, secret, { algorithms: ["HS256"] });
}

3. Web Crypto ベースで Edge ランタイムや Next.js ミドルウェアでも動く jose では、先にシークレットをバイト列にエンコードします：

// lib/jwt.ts — jose (works in Edge runtime and middleware)
import { SignJWT, jwtVerify } from "jose";

const secret = new TextEncoder().encode(process.env.JWT_SECRET);

export async function signToken(payload: Record<string, unknown>) {
  return new SignJWT(payload)
    .setProtectedHeader({ alg: "HS256" })
    .setIssuedAt()
    .setExpirationTime("1h")
    .sign(secret);
}

export async function verifyToken(token: string) {
  const { payload } = await jwtVerify(token, secret, {
    algorithms: ["HS256"],
  });
  return payload;
}

ターミナル派の方へ。openssl や Node の crypto モジュールでも同種のキーを生成できます。アルゴリズムに合わせてバイト数を選んでください：

# HS256 — 32 bytes
openssl rand -hex 32

# HS512 — 64 bytes
openssl rand -hex 64

# Node.js, no openssl needed
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

自前の JWT ではなく認証ライブラリを設定中ですか？ NextAuth Secret ジェネレーター や Better Auth Secret ジェネレーターをご利用ください。必要なのは同種のキーで、変数名が違うだけです。

シークレットをローテーションすると、旧値で署名されたトークンはすべて検証に失敗します。短命なアクセストークンなら軽微な影響で済みますが、長命なトークンでは全員ログアウトになります。漏洩が疑われたら直ちに、疑いがなくても定期的（四半期ごとが一般的）にローテーションしてください。

ダウンタイムなしでローテーションするには、トークンヘッダーにキー ID（kid）を入れ、検証側がトークンの有効期間の間だけ現在と一つ前のシークレットの両方を受け入れるようにし、その後に旧キーを外します。検証側を変更できない場合は、トラフィックの少ない時間帯に実施し、アクセストークンの有効期間を短く保って影響を限定してください。