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
- Set the provider's `type` to a supported value: "oauth", "oidc", "credentials", "email", or "webauthn"
- Verify the provider id in the callback URL matches a provider defined in your auth config
- Upgrade/downgrade @auth/core and provider packages to compatible versions so provider types align
- 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
- Use provider presets from @auth/core/providers instead of hand-rolled definitions
- Only use supported `type` values in custom providers
- Verify the provider id used in URLs matches config keys
- Re-check provider definitions after upgrading @auth/core
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
- Callback route called without provider
- Provider must be WebAuthn
- Dgraph client error: Please provide an API key
- Dgraph client error: Please provide a valid GraphQL endpoint
- Unsupported database type (${typeof db}) in Auth.js Drizzle
AI-assisted analysis of nextauthjs/next-auth@a1a16a5a77 (2026-08-28).
Data as JSON: /api/errors/d987eb7d998e8a8b.
Report an issue: GitHub.