Troubleshooting OIDC sign-in

Each failure below names the symptom, the cause, and the fix. The errors surface 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 (for example a per-branch local host) needs each host registered.

Fix: Register https://<dapp-host>/api/auth/oauth2/callback/<provider-id> for every host the Console 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 is true (the default), which requires the RFC 9207 iss parameter on the authorization response, but the provider does not implement RFC 9207 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 this does not disable issuer checking entirely. Keep the default true for providers that do 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 account is never created.

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

Fix: Populate the user's full-name field 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 the provider to mark the address verified. Do not work around this by suppressing the claim for unverified users.

Signs in as member, not admin

Symptom: Sign-in succeeds, but a user who should be a platform admin resolves to role: member.

Cause: 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 enabling a provider, no one can sign in, and there is no local login option.

Cause: Enabling any provider disables local email/password and passkey sign-in deployment-wide. A misconfigured provider therefore locks every user out, with no in-band fallback.

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

OIDC_MFA_INVALID

Symptom: A signing request that uses 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, which the platform treats as a rejected code).

Fix: Enter a current code from the user's authenticator 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 FusionAuth user holds no authenticator factor, or no FusionAuth user matches the email on the session.

Fix: Enroll an authenticator factor for the user in FusionAuth, and confirm the session email matches that FusionAuth user. 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 platform state, not a rejected code. Retry after a short backoff. If it 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.