${name} cookie was created for a different provider than the

Error message

${name} cookie was created for a different provider than the one handling the callback

What it means

parseCookie throws this error when the decoded cookie payload's `provider` field doesn't match the `options.provider.id` currently handling the callback — a safety check ensuring the state/PKCE check was created for this exact provider. Prevents cross-provider check replay.

Source

Thrown at packages/core/src/lib/actions/callback/oauth/checks.ts:78

  name: keyof CookiesOptions,
  value: string | undefined,
  options: InternalOptions
): Promise<string> {
  try {
    const { logger, cookies, jwt } = options
    logger.debug(`PARSE_${name.toUpperCase()}`, { cookie: value })

    if (!value) throw new InvalidCheck(`${name} cookie was missing`)
    const parsed = await decode<CookiePayload>({
      ...jwt,
      token: value,
      salt: cookies[name].name,
    })
    if (!parsed?.value) throw new Error("Invalid cookie")
    // The check must have been created by the provider currently handling
    // the callback.
    if (parsed.provider !== options.provider?.id) {
      throw new Error(
        `${name} cookie was created for a different provider than the one handling the callback`
      )
    }
    return parsed.value
  } catch (error) {
    throw new InvalidCheck(`${name} value could not be parsed`, {
      cause: error,
    })
  }
}

function clearCookie(
  name: keyof CookiesOptions,
  options: InternalOptions,
  resCookies: Cookie[]
) {
  const { logger, cookies } = options
  const cookie = cookies[name]

View on GitHub (pinned to a1a16a5a77)

Solutions

Start the sign-in flow fresh with the intended provider; don't reuse old authorization URLs across providers.
If you renamed a provider id, redeploy and have users retry sign-in — old cookies are intentionally invalid.
Verify each provider's callback route maps to the correct provider and that signin links specify the right provider id.

Example fix

// before: renamed provider breaks in-flight flows
providers: [Google({ id: "google-workspace" })]
// after: keep the provider id stable
providers: [Google({ id: "google" })]

Defensive patterns

Strategy: try-catch

Validate before calling

// ensure the signin link's provider matches the callback route being hit
const requested = new URL(signinUrl).pathname.split("/").pop()
if (requested !== providerConfig.id) console.warn("Provider id mismatch in signin URL")

Try / catch

try {
  await signIn(providerId)
} catch (e) {
  if (e?.message?.includes("different provider")) {
    // start a fresh sign-in with the intended provider
  }
}

Prevention

Keep provider ids stable across deploys
Generate signin links programmatically from the provider id, never hardcode
Give each provider a distinct callback route derived from its id

When it happens

Trigger: A state cookie generated while starting sign-in with provider A is submitted to the callback of provider B; e.g. two OAuth providers with overlapping callback routes, or the provider id in config changed between flow start and callback.

Common situations: Multiple providers sharing one callback path and the app initiating sign-in with the wrong provider; renaming a provider id (e.g. "google" to "google-workspace") while users had in-flight flows; manually crafted signin URLs pointing at a different provider than the one that set the cookie.

Related errors

AI-assisted analysis of nextauthjs/next-auth@a1a16a5a77 (2026-08-28). Data as JSON: /api/errors/4e5bf8e8fcdbecd3. Report an issue: GitHub.