# Troubleshooting OIDC sign-in Source: https://docs.settlemint.com/docs/developers/sso-oidc/troubleshooting Map each OIDC sign-in failure (invalid redirect, missing issuer, missing name, unverified email, member-not-admin, and lockout) to its cause and fix. 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](/docs/developers/sso-oidc/fusionauth-setup) and [Configure an OIDC provider](/docs/developers/sso-oidc/configure-provider). ## `invalid_redirect_uri` [#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/`, 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:///api/auth/oauth2/callback/` for every host your Console deployment serves. See [FusionAuth setup → Register the redirect URL](/docs/developers/sso-oidc/fusionauth-setup). ## `issuer_missing` [#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](/docs/developers/sso-oidc/configure-provider). ## `name_is_missing` [#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](/docs/developers/sso-oidc/fusionauth-setup). ## `email_is_missing` [#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` [#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](/docs/developers/sso-oidc/fusionauth-setup). 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 [#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](/docs/developers/sso-oidc/deploy-production). ## `OIDC_MFA_INVALID` [#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) [#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](/docs/developers/sso-oidc/fusionauth-setup). ## `OIDC_MFA_UNAVAILABLE` [#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](/docs/developers/sso-oidc/configure-provider).