Troubleshooting OIDC sign-in

Each OIDC sign-in failure maps to a named cause and a concrete fix. You will see errors either on the provider's page before the redirect back, or on the DALP error page after the callback. For setup context, see FusionAuth setup and Configure an OIDC provider.

invalid_redirect_uri

Symptom: the provider rejects the request before showing its login form, citing an invalid redirect URI.

Cause: the callback URL DALP sends is not registered on the provider's application. DALP's callback is /api/auth/oauth2/callback/<provider-id>, and the host must match exactly. A deployment that answers on more than one host, such as a per-branch local host, needs each host registered.

Fix: register https://<dapp-host>/api/auth/oauth2/callback/<provider-id> for every host your Console deployment serves. See FusionAuth setup → Register the redirect URL.

issuer_missing

Symptom: the provider login succeeds, but the callback fails on the DALP side with issuer_missing.

Cause: requireIssuerValidation defaults to true, which requires the RFC 9207 iss parameter on the authorization response. The provider lacks RFC 9207 support and omits it. FusionAuth is the common case.

Fix: set requireIssuerValidation: false for that provider. The ID token's iss claim is still validated against discovery, so your issuer check remains active. Keep the default true for providers that support RFC 9207. See Configure an OIDC provider → Issuer validation and RFC 9207.

name_is_missing

Symptom: the callback fails with name_is_missing; the platform never creates the account.

Cause: the provider returned no name claim. DALP requires a name to create the user. Some providers derive name from a dedicated full-name attribute rather than concatenating first and last name. If that attribute is empty, no name claim is emitted.

Fix: populate the user's full-name entry at the provider. For FusionAuth, set the user's Full name (the fullName field). First and last name alone are not enough. See FusionAuth setup → Set the user's full name.

email_is_missing

Symptom: the callback fails with email_is_missing even though the user has an email at the provider.

Cause: the provider returned email_verified: false (or the string "false"). DALP rejects an explicitly-unverified email because an unverified address is an attacker-choosable identity anchor. An omitted email_verified is accepted; only an explicit false is rejected.

Fix: verify the user's email at the provider, or configure it to mark the address verified. Do not work around this by suppressing the claim for unverified users in your integration.

Signs in as member, not admin

When sign-in succeeds but a user who should be a platform admin resolves to role: member, the adminClaim value is not present in the profile DALP reads. Two frequent reasons:

• The admin role or group is not assigned to the user at the provider.
• The provider emits roles only in the access token, while DALP reads the ID token, falling back to userinfo only when the ID token lacks a subject or email. FusionAuth behaves this way by default: application roles never reach the ID token without a populate lambda.

Fix:

• Confirm the user holds the adminClaim value in a roles or groups array claim.
• For FusionAuth, add the JWT-populate lambda that copies registration.roles into the ID token and assign it to the application's ID-token populate slot. See FusionAuth setup → Add a lambda to put roles in the ID token.

Because the role re-derives on every login, the fix takes effect on the user's next sign-in. Verify with GET /api/auth/get-session.

Everyone is locked out after enabling SSO

Symptom: after activating a provider, no one can sign in, and the email/password login option is gone.

Cause: activating any provider disables local email/password and passkey sign-in deployment-wide. A bad OIDC configuration locks every user out with no in-band fallback.

Fix: redeploy with an empty provider list (oidcProviders: []) to restore sign-in, fix your OIDC configuration in a staging environment, then re-enable. See Deploy OIDC in production → Recover from a lockout.

OIDC_MFA_INVALID

Symptom: a signing request using the OIDC_MFA verification method fails with OIDC_MFA_INVALID (HTTP 403).

Cause: FusionAuth rejected the authenticator code. The code was wrong or expired, or the user's tenant requires an additional factor the platform does not drive in this version. FusionAuth returns a multi-method response in that case, which the platform treats as a rejected code.

Fix: enter a current code from the user's authenticator app and retry. TOTP codes are single-use and valid for a short window, so generate the code immediately before the request. This result is terminal for the submitted code; retrying the same code fails again.

USER_MISSING_2FA (OIDC MFA)

Symptom: an OIDC_MFA signing request fails with USER_MISSING_2FA (HTTP 403).

Cause: the user has no authenticator factor the platform can verify against. Either the user holds no authenticator factor in FusionAuth, or no account there matches the session email.

Fix: enroll an authenticator factor for the user in FusionAuth, and confirm the session email matches that account. Enable the Authenticator method on the tenant first if it is off. See FusionAuth setup → Enable OIDC wallet verification.

OIDC_MFA_UNAVAILABLE

Symptom: an OIDC_MFA signing request fails with OIDC_MFA_UNAVAILABLE (HTTP 503).

Cause: the platform could not complete the verification against FusionAuth. The provider was unreachable or returned a server error, or no apiKey is configured for OIDC wallet verification.

Fix: this is a retryable error, not a rejected code. Retry after a short backoff. If the error persists, confirm OIDC_PROVIDER_MFA_API_KEY is set and valid and that the platform can reach the issuer host. See Configure an OIDC provider → OIDC MFA enablement predicate.