# 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 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](/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/<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 dapp 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` 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](/docs/developers/sso-oidc/configure-provider).

## `name_is_missing` [#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](/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 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` [#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](/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 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](/docs/developers/sso-oidc/deploy-production).