SettleMint
SSO sign-in (OIDC)

SSO sign-in (OIDC)

Configure an external OpenID Connect identity provider as the sign-in method for a DALP deployment, with FusionAuth as the worked example.

DALP can delegate account sign-in to an external OpenID Connect (OIDC) identity provider. Configuration is provider-neutral: the same auth.oidcProviders block works against FusionAuth, Okta, Auth0, or any standards-compliant OIDC issuer. No provider is special-cased in code.

This section uses FusionAuth as the worked example because it surfaces the two integration requirements operators most often miss — the name claim source and how provider roles reach the token DALP reads.

Related pages:

Enablement is all-or-nothing

DALP treats the configured provider list as a deployment-wide switch. A provider counts as configured only when its id, issuer, clientId, and clientSecret are all set; partially-filled entries are ignored.

When at least one provider is fully configured, the external IdP becomes the sole login method. Local email and password sign-in is disabled server-side, and passkey sign-in paths are rejected. There is no in-band fallback — recovery from a misconfigured provider is a redeploy with an empty provider list (see Deploy OIDC in production).

Rendering diagram...

Configuring a provider disables local login

Enabling any OIDC provider removes email/password and passkey sign-in for the whole deployment. Verify the provider end-to-end in a non-production environment before enabling it where operators depend on access.

What the provider must supply

DALP reads the user profile from the provider's ID token (falling back to the userinfo endpoint only when the ID token lacks a subject or email). Three claims drive sign-in and authorization.

DALP needSource claimWhat happens if it is missing or wrong
Display name (required)nameSign-in fails — the account cannot be created without a name.
Identity anchora verified emailAn explicit email_verified: false is rejected by design.
Platform adminthe adminClaim value inside a roles or groups array, or a direct boolean claim named by adminClaimThe user signs in as a regular member.

Admin is deny-by-default: when adminClaim is empty, no profile is ever promoted to platform admin. The role is re-derived on every login, so changing a user's claim at the IdP promotes or demotes them on their next sign-in.

How sign-in flows

Rendering diagram...

Each labelled failure has a cause and fix in Troubleshooting.

Next steps

On this page