Paste the Auth.js error.
Get the fix.

error=Configuration

/api/auth/error?error=Configuration

This is a cover, not the real error. Auth.js only sends a few error types to the browser (AccessDenied, Verification, OAuthAccountNotLinked and a handful more). Everything else, like a missing secret or a database failure, shows up as Configuration so it can't leak details.

usually because

• –The real error is in your server logs, on a line starting with [auth][error]
• –Most often MissingSecret, UntrustedHost or an AdapterError

fix

1. 1.Open the logs where the app runs (Vercel → Deployments → Logs, or your terminal)
2. 2.Find the [auth][error] line and paste it into the box above
3. 3.Add debug: true to your NextAuth config temporarily if the line isn't there

MissingSecret

[auth][error] MissingSecret: Please define a `secret`. Read more at https://errors.authjs.dev#missingsecret

Auth.js has no secret to encrypt cookies and tokens with. It reads AUTH_SECRET (or AUTH_SECRET_1, _2, _3 for rotation). next-auth v5 still falls back to the old NEXTAUTH_SECRET.

usually because

• –AUTH_SECRET is in .env.local but not in your host's environment variables
• –The variable was added after the last deploy, so the running build doesn't see it
• –A typo like AUTH_SECRETS or NEXT_PUBLIC_AUTH_SECRET

fix

1. 1.Generate one: npx auth secret (or openssl rand -base64 33)
2. 2.Add AUTH_SECRET to the production environment on your host
3. 3.Redeploy so the new value is picked up
4. 4.Never prefix it with NEXT_PUBLIC_: that ships it to the browser

# at least 32 random characters
AUTH_SECRET="paste-the-output-of-npx-auth-secret"

UntrustedHost

[auth][error] UntrustedHost: Host must be trusted. URL was: https://your-app.com/api/auth/session. Read more at https://errors.authjs.dev#untrustedhost

Auth.js builds callback URLs from the request's Host header and refuses to trust it by default in production. In development (NODE_ENV not production) it trusts the host automatically, which is why this only appears after you deploy.

usually because

• –Running next start, Docker, Railway, Fly, Render or a VPS behind a proxy
• –Vercel and Cloudflare Pages are detected automatically (VERCEL / CF_PAGES env vars), most other hosts are not

fix

1. 1.Set trustHost: true in your NextAuth config, or
2. 2.Set AUTH_TRUST_HOST=true in the production environment
3. 3.Setting AUTH_URL also counts as trusting the host

export const { handlers, auth, signIn, signOut } = NextAuth({
  trustHost: true, // needed for next start, Docker and most non-Vercel hosts
  providers: [GitHub],
});

GitHub: redirect_uri mismatch

error=redirect_uri_mismatch · The redirect_uri is not associated with this application.

The callback URL Auth.js sent to GitHub doesn't match the one registered on your GitHub OAuth app. A GitHub OAuth app has one callback URL, so the app you made for localhost can't also serve production.

usually because

• –Signing in on production with the localhost OAuth app's client ID
• –http vs https, www vs no www, or a different port
• –A preview deployment URL that changes on every deploy

fix

1. 1.Create a second GitHub OAuth app for production (github.com/settings/developers)
2. 2.Set its callback URL to https://your-domain.com/api/auth/callback/github
3. 3.Put that app's ID and secret in production as AUTH_GITHUB_ID and AUTH_GITHUB_SECRET
4. 4.For previews, Auth.js supports a stable redirect proxy via AUTH_REDIRECT_PROXY_URL

Homepage URL:   https://your-domain.com
Callback URL:   https://your-domain.com/api/auth/callback/github

Redirected to localhost after deploy

https://your-app.com → sign in → http://localhost:3000/api/auth/callback/github

If AUTH_URL or NEXTAUTH_URL is set, next-auth v5 rewrites the request's origin to it. A localhost value copied into production sends every user back to localhost.

usually because

• –NEXTAUTH_URL=http://localhost:3000 copied from a v4 tutorial into the host's env vars
• –AUTH_URL left over from local testing

fix

1. 1.Delete AUTH_URL and NEXTAUTH_URL from production. v5 infers the host from the request
2. 2.Only set AUTH_URL when Auth.js lives under a different base path
3. 3.Redeploy

OAuthAccountNotLinked

/login?error=OAuthAccountNotLinked

Someone already has an account with this email, created with a different sign-in method (say, a magic link), and now tries GitHub. For security, Auth.js won't attach the new provider to an existing user who isn't signed in.

usually because

• –Same email used with email magic link first, GitHub second (or the reverse)
• –Test users left in your dev database

fix

1. 1.Show a friendly message on your sign-in page: "Sign in the way you did the first time"
2. 2.Let signed-in users link extra providers from their account page
3. 3.allowDangerousEmailAccountLinking: true on a provider turns on auto-linking. Only use it if you trust that provider to verify emails

const messages: Record<string, string> = {
  OAuthAccountNotLinked: "That email already has an account. Sign in the way you did the first time.",
  Verification: "That sign-in link expired or was already used. Request a new one.",
};

error=Verification

/api/auth/error?error=Verification

The magic-link token wasn't found or has expired. Each link works once, and the email provider's default lifetime is 24 hours.

usually because

• –The link was clicked twice, or a newer link replaced it
• –The link is older than 24 hours
• –The verification token was written to a different database than the one the app reads now

fix

1. 1.Ask the user to request a new link, and say so on the error page
2. 2.Make sure dev and prod don't share or swap DATABASE_URL
3. 3.Raise maxAge on the email provider only if you have a reason to

MissingAdapter

[auth][error] MissingAdapter: Email login requires an adapter. Read more at https://errors.authjs.dev#missingadapter

Magic links (Email / Nodemailer / Resend providers) and session: { strategy: "database" } both need a database adapter to store tokens and sessions.

usually because

• –Added the Nodemailer or Resend provider without an adapter
• –Set strategy: "database" without an adapter
• –Imported the adapter but passed it in only one of two config files

fix

1. 1.Install @auth/prisma-adapter (v5 adapters live under @auth/, not @next-auth/)
2. 2.Pass adapter: PrismaAdapter(db) to NextAuth
3. 3.Add the User, Account, Session and VerificationToken models and run a migration

import { PrismaAdapter } from "@auth/prisma-adapter";
import { db } from "@/lib/db";

export const { handlers, auth, signIn, signOut } = NextAuth({
  adapter: PrismaAdapter(db),
  session: { strategy: "database" },
  providers,
});

AdapterError / table does not exist

[auth][error] AdapterError … The table `main.User` does not exist in the current database.

One of the adapter's database calls failed. The cause line under it says why, and with Prisma it's usually a missing table or an unreachable database.

usually because

• –Migrations never ran against the production database
• –DATABASE_URL points to SQLite on a serverless host, where the file doesn't persist
• –Schema models renamed so they no longer match what the adapter expects

fix

1. 1.Run npx prisma migrate deploy against production (or prisma db push while prototyping)
2. 2.Use Postgres in production. SQLite files don't survive serverless deploys
3. 3.Set debug: true once to see which adapter_ method failed

InvalidCheck (PKCE / state)

[auth][error] InvalidCheck: pkceCodeVerifier value could not be parsed. Read more at https://errors.authjs.dev#invalidcheck

Auth.js sets a short-lived cookie when sign-in starts and checks it when the provider sends the user back. The cookie was missing on the way back.

usually because

• –Starting on 127.0.0.1 and coming back to localhost (or www vs no www): different cookie jars
• –The callback lands on a different domain than the one sign-in started on
• –Cookies blocked in the browser, or a custom cookies config

fix

1. 1.Use one exact origin everywhere: the address bar, the OAuth app and any AUTH_URL
2. 2.Redirect www to the apex domain (or the reverse) at the host
3. 3.Remove custom cookies options unless you need them

JWTSessionError

[auth][error] JWTSessionError: Read more at https://errors.authjs.dev#jwtsessionerror  [auth][cause]: Error: no matching decryption secret

With strategy "jwt", Auth.js couldn't decrypt the session cookie. The cookie was encrypted with a different secret, so it's destroyed and the user is signed out.

usually because

• –AUTH_SECRET changed (or differs between preview and production)
• –An old cookie from another app on localhost:3000

fix

1. 1.For one user: clear cookies for the site and sign in again
2. 2.To rotate without signing everyone out, set the new secret as AUTH_SECRET and keep the old one as AUTH_SECRET_1 for a while
3. 3.Use the same secret on every deployment that shares the domain

SessionTokenError

[auth][error] SessionTokenError: Read more at https://errors.authjs.dev#sessiontokenerror

With strategy "database", Auth.js couldn't read the session from the database. The adapter is misconfigured or the database can't be reached.

usually because

• –Database down or DATABASE_URL wrong in this environment
• –Connection limit hit on serverless Postgres without pooling

fix

1. 1.Check the cause line and your database dashboard
2. 2.Use your provider's pooled connection string on serverless
3. 3.Reuse one Prisma client (a global singleton in dev)

AccessDenied

/api/auth/error?error=AccessDenied

Your signIn callback returned false (or threw), or the user clicked Cancel on the provider's consent screen.

usually because

• –An allow-list in callbacks.signIn that doesn't include this email
• –The user declined on GitHub

fix

1. 1.Log the inputs in callbacks.signIn to see why it returned false
2. 2.Return a redirect path string from signIn instead of false to send blocked users somewhere useful

MissingCSRF

[auth][error] MissingCSRF: CSRF token was missing during an action signin. Read more at https://errors.authjs.dev#missingcsrf

A sign-in or sign-out POST arrived without Auth.js's CSRF cookie and token. Often it's a hand-rolled fetch to /api/auth/signin instead of the provided helpers.

usually because

• –fetch('/api/auth/signin/…', { method: 'POST' }) written by hand
• –A form posting to the Auth.js endpoint from another origin

fix

1. 1.Use signIn() from your auth.ts in a Server Action, or signIn from next-auth/react in a Client Component
2. 2.Don't call the /api/auth endpoints directly

import { signIn } from "@/auth";

<form action={async () => { "use server"; await signIn("github", { redirectTo: "/dashboard" }); }}>
  <button>Sign in with GitHub</button>
</form>

v4 code in a v5 app (getServerSession, authOptions)

Module '"next-auth"' has no exported member 'NextAuthOptions'. · getServerSession(authOptions)

Your AI agent wrote NextAuth v4 code. A lot of tutorials and training data are from v4, so agents mix the two APIs unless you tell them which version you use.

usually because

• –getServerSession(authOptions) and next-auth/next imports
• –NextAuthOptions (renamed NextAuthConfig)
• –export { default } from "next-auth/middleware"
• –@next-auth/prisma-adapter (now @auth/prisma-adapter)

fix

1. 1.Call auth() from your auth.ts everywhere on the server
2. 2.Export auth as proxy in proxy.ts (Next.js 16 renamed middleware.ts)
3. 3.Add a rule telling your agent the project uses Auth.js v5 and to check package.json before writing auth code

- import { getServerSession } from "next-auth/next"
- const session = await getServerSession(authOptions)
+ import { auth } from "@/auth"
+ const session = await auth()