nextauthjs/next-auth · error · InvalidProvider

Callback for provider type (${provider.type}) is not support

Error message

Callback for provider type (${provider.type}) is not supported

What it means

InvalidProvider is thrown at the end of the callback route when the resolved provider's type does not match any supported callback branch (oauth/oidc/credentials/email/webauthn already handled earlier). It means Auth.js was asked to process a callback for a provider type it cannot handle in that route.

Source

Thrown at packages/core/src/lib/actions/callback/index.ts:528

      })

      // Handle first logins on new accounts
      // e.g. option to send users to a new account landing page on initial login
      // Note that the callback URL is preserved, so the journey can still be resumed
      if (isNewUser && pages.newUser) {
        return {
          redirect: `${pages.newUser}${
            pages.newUser.includes("?") ? "&" : "?"
          }${new URLSearchParams({ callbackUrl })}`,
          cookies,
        }
      }

      // Callback URL is already verified at this point, so safe to use if specified
      return { redirect: callbackUrl, cookies }
    }

    throw new InvalidProvider(
      `Callback for provider type (${provider.type}) is not supported`
    )
  } catch (e) {
    if (e instanceof AuthError) throw e
    const error = new CallbackRouteError(e as Error, { provider: provider.id })
    logger.debug("callback route error details", { method, query, body })
    throw error
  }
}

async function handleAuthorized(
  params: Parameters<InternalOptions["callbacks"]["signIn"]>[0],
  config: InternalOptions
): Promise<string | undefined> {
  let authorized
  const { signIn, redirect } = config.callbacks
  try {
    authorized = await signIn(params)

View on GitHub (pinned to a1a16a5a77)

Solutions

  1. Set the provider's `type` to a supported value: "oauth", "oidc", "credentials", "email", or "webauthn"
  2. Verify the provider id in the callback URL matches a provider defined in your auth config
  3. Upgrade/downgrade @auth/core and provider packages to compatible versions so provider types align
  4. For custom providers, extend the OIDC or OAuth template rather than inventing a new type

Example fix

// before
const MyProvider = { id: "myid", type: "oauth2", ... }
// after
const MyProvider = { id: "myid", type: "oidc", issuer: "https://...", ... }
Defensive patterns

Strategy: validation

Validate before calling

const supported = ["oauth", "oidc", "credentials", "email", "webauthn"]
for (const p of providers) {
  if (!supported.includes(p.type)) {
    throw new Error(`Provider ${p.id} has unsupported type: ${p.type}`)
  }
}

Type guard

function isSupportedProviderType(t: string): boolean {
  return ["oauth","oidc","credentials","email","webauthn"].includes(t)
}

Try / catch

try {
  await signIn(providerId)
} catch (e) {
  if ((e as Error).message.startsWith("Callback for provider type")) {
    // fix provider `type` in auth config
  }
}

Prevention

When it happens

Trigger: Requesting /api/auth/callback/<id> where <id> resolves to a provider whose type is unsupported for callbacks — e.g. a custom provider object with a mistyped or unrecognized `type` field, or calling the callback route for a provider that only supports sign-in (not callback processing).

Common situations: Defining a custom provider with type set to an arbitrary string instead of a supported value; typos like type: "oauth2" instead of "oauth"; version upgrades where a previously accepted provider type was removed; pointing the client at the wrong provider id in the callback URL.

Related errors


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