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.
This section covers the overview, enablement model, claim requirements, and sign-in flow. Related pages: Configure an OIDC provider, FusionAuth setup, Deploy OIDC in production, Troubleshooting, and Authentication.
Enablement is all-or-nothing
DALP treats the configured provider list as a deployment-wide switch for sign-in. A provider counts as configured for sign-in only when its id, issuer, clientId, and clientSecret are all set; partially-filled entries are ignored.
When at least one provider is fully configured for sign-in, the external IdP becomes the sole login method. The platform disables local email and password sign-in server-side and rejects passkey sign-in paths. No in-band fallback exists: recovery from a misconfigured provider requires a redeploy with an empty provider list (see Deploy OIDC in production).
Beyond sign-in: OIDC wallet verification
Sign-in is not the only place DALP uses an OIDC provider. The same provider can back OIDC wallet verification: when a signing request declares the OIDC_MFA verification method, the platform runs a server-side TOTP check against the provider and treats success as authorization for that one signing operation. OIDC wallet verification sits alongside PIN, OTP, and recovery codes as a way to authorize signing, and does not replace sign-in.
OIDC wallet verification is enabled separately from sign-in, through different fields (apiKey and applicationId). Configuring it does not disable local login. A deployment can pair it with local password sign-in or with OIDC sign-in. The two capabilities are independent.
In this version, OIDC_MFA is available to API and SDK callers that supply it in a request's walletVerification. The Console does not offer it as a selectable method. Configure it in the OIDC MFA enablement predicate, set up FusionAuth in FusionAuth setup, and map its failures in Troubleshooting.
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 need | Source claim | What happens if it is missing or wrong |
|---|---|---|
| Display name (required) | name | Sign-in fails: the platform cannot create the account without a name. |
| Identity anchor | a verified email | An explicit email_verified: false is rejected by design. |
| Platform admin | the adminClaim value inside a roles or groups array, or a direct boolean claim named by adminClaim | The user signs in as a regular member. |
Admin assignment is deny-by-default: when adminClaim is empty, the platform never promotes a profile to platform admin. The role re-derives 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
Each labelled failure has a cause and fix in Troubleshooting.
Next steps
- Map every configuration field and its environment variable in Configure an OIDC provider.
- Follow the end-to-end FusionAuth setup.
- Plan the rollout with Deploy OIDC in production.
Change DALP platform administrator roles through the API
Update platform administrator role assignments through the API when operating responsibilities, least-privilege reviews, or provisioning workflows change.
Configure a DALP OIDC sign-in provider
Reference for every auth.oidcProviders field, its environment variable, default, and the claim contract any OIDC identity provider must satisfy for DALP sign-in.