NextAuth Secret Generator

NextAuth.js uses this secret for everything that must be tamper-proof: it signs and encrypts the JWT stored in the session cookie (JWE with A256CBC-HS512 by default), signs CSRF tokens, and hashes email verification and magic-link tokens before they are stored. Without it, anyone could forge a session cookie and sign in as any user.

In production both NextAuth.js v4 and Auth.js v5 refuse to start without a secret. It must be a high-entropy random value that only your server knows — never a password, a project name or anything you could type from memory. 32 bytes (256 bits) is the recommended size and is what this generator produces by default.

NextAuth.js v4 reads NEXTAUTH_SECRET (alongside NEXTAUTH_URL). Auth.js v5 — the rebranded next major version of NextAuth — reads AUTH_SECRET instead, and drops the NEXTAUTH_URL requirement because it infers the host from the request. The secret itself is the same kind of value; only the variable name changed.

Auth.js v5 still falls back to NEXTAUTH_SECRET for backwards compatibility, so a half-migrated project keeps working — but pick one name per project so nobody has to guess which variable is authoritative. If you are starting fresh, use AUTH_SECRET.

1. Add the generated key to your .env file under the variable name your version expects:

# .env — Auth.js v5
AUTH_SECRET=your-generated-secret

# .env — NextAuth.js v4
NEXTAUTH_SECRET=your-generated-secret
NEXTAUTH_URL=http://localhost:3000

2. Both versions pick the secret up from the environment automatically. You only need the secret option if you want to load it from somewhere else:

// auth.ts — Auth.js v5
import NextAuth from "next-auth";

export const { handlers, auth, signIn, signOut } = NextAuth({
  // Auth.js reads AUTH_SECRET from the environment automatically —
  // set the option only when you need to override it.
  secret: process.env.AUTH_SECRET,
  providers: [/* GitHub, Google, Resend ... */],
});

// pages/api/auth/[...nextauth].ts — NextAuth.js v4
// export default NextAuth({
//   secret: process.env.NEXTAUTH_SECRET,
//   providers: [...],
// });

3. On Vercel, add the same variable in Project Settings → Environment Variables (or via the CLI), and use a different value for Production and Preview. Redeploy after changing it — environment variables are baked in at build time for serverless functions.

# Vercel CLI — set the secret per environment
vercel env add AUTH_SECRET production
vercel env add AUTH_SECRET preview

# NextAuth v4 projects use NEXTAUTH_SECRET instead
vercel env add NEXTAUTH_SECRET production

Prefer a terminal? The Auth.js CLI and openssl produce the same 32-byte Base64 secret this page does — the browser version simply skips the terminal:

# Auth.js CLI — writes AUTH_SECRET into .env.local
npx auth secret

# or with openssl
openssl rand -base64 32

Using a different auth library? Try the Better Auth secret generator or the universal auth secret generator for any other environment variable.

Rotating the secret invalidates every session cookie and every pending verification token signed with the old value — all users are signed out and must log in again. That is the intended behavior: it is exactly what you want after a leak or when an engineer with production access leaves.

To rotate: generate a new key, update the environment variable in every environment that used the old one, and redeploy. There is no dual-key grace period in NextAuth.js, so schedule rotations at low-traffic hours if the forced re-login matters to you.