SSO with any OIDC or SAML provider
Generic OIDC and SAML 2.0 setup for any identity provider that is not covered by a named dFlow walkthrough.
Use this guide when your identity provider is not covered by a dedicated page, or when you prefer SAML 2.0 over OIDC. Manage providers from Account → Single Sign-On.
Named walkthroughs:
- Enterprise SSO (includes Microsoft Entra)
- SSO with Google Workspace
- SSO with Okta
- SSO with Auth0
- SSO with Keycloak
OIDC (recommended when available)
1. Pick a Provider ID in dFlow
Open Add OIDC and choose a stable Provider ID (for example acme-oidc). Copy the live Redirect URI:
{your-dflow-url}/api/auth/sso/callback/<provider-id>Register that exact URI at your IdP as the callback / redirect URI for a confidential web OIDC client.
2. Collect values from your IdP
| Value | Where it usually appears |
|---|---|
| Issuer URL | OIDC discovery issuer, often ending without a path or with /oauth2/default, /v2.0, or /realms/<realm> |
| Client ID | Application / client identifier |
| Client secret | Confidential client secret |
| Discovery | {issuer}/.well-known/openid-configuration (or a vendor-specific discovery URL) |
Your IdP must support the authorisation code flow. PKCE is recommended.
3. Fill in the dFlow modal
| Field | Guidance |
|---|---|
| Provider ID | Matches the redirect URI suffix |
| Email domains | Domains used at the dFlow sign-in screen |
| Issuer URL | From your IdP |
| Client ID / Client secret | From your IdP |
| Scopes | openid email profile unless your IdP requires different names for email |
| Token auth method | Prefer client_secret_basic; use client_secret_post if the IdP documents that requirement |
| Discovery endpoint | Optional override when discovery is not at the standard well-known path |
| Authorization / Token / JWKS endpoints | Leave blank when discovery works |
| Use PKCE | On unless the IdP rejects PKCE |
| Skip discovery | Off unless you must hard-code endpoints |
4. Trusted origins and test
Save the provider, confirm the issuer origin appears under Trusted origins, then sign out and test with an email on a registered domain.
SAML 2.0
1. Pick a Provider ID in dFlow
Open Add SAML and choose a Provider ID (for example acme-saml). The dialog shows the ACS / callback URL:
{your-dflow-url}/api/auth/sso/callback/<provider-id>Register that URL as the Assertion Consumer Service (ACS) URL in your IdP SAML application. Set the audience / entity ID according to your IdP's requirements (often your dFlow origin or a value you also paste into dFlow's Audience field).
2. Collect values from your IdP
| Value | dFlow field |
|---|---|
| IdP entity ID / issuer | Issuer URL |
| SSO URL / login URL | Entry point / SSO URL |
| X.509 signing certificate (PEM) | IdP certificate |
| Metadata XML (optional) | IdP metadata XML |
| Audience / SP entity ID (optional) | Audience |
| Signature algorithm | Signature algorithm (sha256 is typical) |
3. Fill in the dFlow modal
- Enter Provider ID and Email domains.
- Paste Issuer URL, Entry point / SSO URL, and IdP certificate.
- Optionally paste IdP metadata XML and Audience.
- Set signing options to match the IdP (assertion signing on is common).
- Save.
4. Test
Sign out, enter an email on a registered domain, complete IdP login, and confirm you return to dFlow signed in.
Troubleshooting checklist
- Redirect / ACS URL matches character-for-character (scheme, host, path, no extra slash)
- Email domain on the provider matches what users type at sign-in
- Client secret is the secret value, not a key id
- Discovery URL is reachable from the dFlow server
- Trusted origins include every host involved in discovery or login when they differ from the issuer
Related
- Enterprise SSO — redirect URI rules and shared troubleshooting