signIn server action fails with Configuration error on Next.js 16

[TaylorBurke]

Environment

  System:
    OS: Windows 11 10.0.26200
    CPU: (16) x64 AMD Ryzen 7 4800H with Radeon Graphics
  Binaries:
    Node: 24.11.1
    npm: 11.6.2
  npmPackages:
    next: 16.1.6
    next-auth: 5.0.0-beta.30
    react: 19.2.3

Reproduction URL

https://github.com/TaylorBurke/nextauth-nextjs16-repro

Describe the issue

The signIn server action exported from NextAuth() fails with a Configuration error on Next.js 16. The HTTP handler (handlers.GET/handlers.POST) works correctly for the same request.

The reproduction is a minimal Next.js 16 app with a single GitHub OAuth provider:

// src/lib/auth.ts
import NextAuth from 'next-auth'
import GitHub from 'next-auth/providers/github'

export const { handlers, auth, signIn, signOut } = NextAuth({
  basePath: '/api/auth',
  providers: [GitHub],
})

The login page uses the documented server action pattern:

import { signIn } from '@/lib/auth'

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

Clicking the button redirects to the error page with ?error=Configuration instead of redirecting to GitHub OAuth.

What works:

• GET /api/auth/csrf — returns CSRF token
• GET /api/auth/providers — returns providers
• GET /api/auth/session — returns null
• GET /api/auth/signin — renders built-in signin page (which uses direct form POST, not server actions)
• POST /api/auth/signin/github via curl with proper CSRF cookie — returns 302 to GitHub OAuth
• Calling Auth() directly with a manually constructed request — works

The issue is specifically in the signIn server action in next-auth/lib/actions.js, which constructs a synthetic request via createActionURL() and passes it to Auth(). Something in this request construction fails on Next.js 16. The error is caught in Auth() and converted to the generic Configuration type before redirecting.

The bug reproduces both on localhost (HTTP) and on Vercel (HTTPS).

Workaround: Use direct HTML form POST (the same pattern the built-in signin page at /api/auth/signin uses) with a client component that fetches the CSRF token browser-side.

How to reproduce

1. Clone the reproduction repo
2. Copy .env.example to .env.local and fill in GitHub OAuth credentials + a secret
3. npm install && npm run dev
4. Visit http://localhost:3000
5. Click "Sign in with GitHub (server action)"
6. Observe redirect to /api/auth/error?error=Configuration

For comparison, visit /api/auth/signin to see the built-in signin page — clicking "Sign in with GitHub" there works correctly because it uses direct form POST, not the server action.

Expected behavior

Clicking the server action sign-in button should redirect to GitHub's OAuth authorization page, the same way the built-in signin page and direct HTTP POST do.

[TaylorBurke]

Worth noting: the server action pattern used in this reproduction follows the Auth.js documentation for login, which recommends calling signIn as a server action.

[jonas-is-coding]

This looks like a type boundary problem rather than a runtime logic issue. The most reliable fix is to make the input/output contract explicit at the entry point, validate unknown data before it reaches typed code, and avoid widening to any in shared paths. If the failure appeared after an upgrade, pinning to the previous known-good version while narrowing the contract usually removes the regression without introducing hidden behavior changes.

[TaylorBurke]

Thanks for the input. I traced through the source to pin down where this breaks — sharing in case it's useful for the maintainers.

The failure path:

next-auth/lib/actions.js lines 10-12 pass headers.get("x-forwarded-proto") as the protocol param to createActionURL:

const signInURL = createActionURL("signin",
    // @ts-expect-error `x-forwarded-proto` is not nullable, next.js sets it by default
    headers.get("x-forwarded-proto"), headers, process.env, config)

When AUTH_URL/NEXTAUTH_URL aren't set, createActionURL (@auth/core/lib/utils/env.js:82) falls back to header detection:

const detectedProtocol = headers.get("x-forwarded-proto") ?? protocol ?? "https"

Both the protocol param and the header fallback come from the same headers.get("x-forwarded-proto") call — so if that header is absent in Next.js 16's server action context, both are null and it defaults to "https". On local dev that's wrong (http), and on Vercel the constructed URL can still mismatch depending on what x-forwarded-host returns.

Whatever error this produces gets caught in @auth/core/index.js:120 and masked:

const type = isClientSafeErrorType ? error.type : "Configuration"

Every error that isn't in the 8-type clientErrors set becomes "Configuration" — which is why the error message gives no hint about the actual failure.

Additionally, actions.js has no try/catch around the Auth() call (line 44), so when raw mode re-throws AuthError instances (index.js:124), they propagate as unhandled server action errors.

Possible fixes:

• Validate/log the URL from createActionURL before constructing the Request
• Add error handling in actions.js around the Auth() call
• Use the host header as a fallback when x-forwarded-proto is absent (which createActionURL already does internally for host detection, but the protocol param from actions.js bypasses that)

Reproduction repo is in the issue description. Happy to test any patches against it.