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 dapp 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.