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:
- Configure an OIDC provider
- FusionAuth setup
- Deploy OIDC in production
- Troubleshooting
- 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. 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).
Configuring a provider for sign-in disables local login
Configuring a provider for sign-in (a complete clientId + clientSecret
entry) 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. OIDC wallet verification configuration
(see below) does not have this effect.
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. It 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. It is not offered as a selectable method in the operator dapp. 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 account cannot be created 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 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
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 admin roles
Update platform administrator role assignments through the API when operating responsibilities, least-privilege reviews, or provisioning workflows change.
Configure an OIDC 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.