Skip to content
Back to

Identity providers

An identity provider (IdP) creates and maintains identity information and provides authentication services to your applications. Single sign-on (SSO) lets users access multiple services with one set of credentials, which improves convenience and reduces password sprawl.

Each Fontana workspace runs self-hosted Zitadel as its identity plane. Zitadel can act as your primary user store, or as an identity broker that federates external identity providers (corporate Entra ID, Okta, Google, SAML IdPs, LDAP, and more). Your Flow application talks only to Zitadel; Zitadel handles protocol differences with upstream IdPs.

External identity providers and SSO

Section titled “External identity providers and SSO”

Many users already have accounts with popular IdPs or workplace directories. Allowing them to sign in with those accounts means they do not need new usernames and passwords for Flow, which improves adoption and reduces support load.

External IdPs also bring mature security controls (password policies, conditional access, device compliance) that your organisation may already enforce. Integrating them through Zitadel keeps that investment while Fontana stays a standard OIDC client.

Adding external identity providers

Section titled “Adding external identity providers”

With Zitadel you can integrate:

  • Social logins - Google, GitHub, Apple, and similar templates
  • Enterprise IdPs - Entra ID (OIDC or SAML), Okta, Auth0, Keycloak
  • Directory services - LDAP and OpenLDAP
  • Custom IdPs - any provider that speaks OIDC or SAML via generic templates

By default, Zitadel can serve as the primary user store (email and password plus MFA). You can also require or allow external IdPs only, depending on login policy.

Sign-in journey (external IdP)

Section titled “Sign-in journey (external IdP)”
  1. User chooses Sign in with an external provider on the Flow login screen (when enabled in login policy).
  2. Flow redirects to Zitadel; Zitadel forwards the user to the external IdP.
  3. After successful authentication, the user returns through Zitadel to Flow with tokens and profile claims.
  4. New users: Zitadel can auto-create an account, or prompt to link to an existing local account, depending on template settings.
  5. Returning users: Zitadel issues session tokens; Flow projects the user’s Zitadel project role into Convex on login (see Roles and RBAC).

Configure identity providers in Zitadel

Section titled “Configure identity providers in Zitadel”

Your platform or security team configures IdPs in the Zitadel Management Console for each workspace instance.

Enable external IdP login
Section titled “Enable external IdP login”
  1. Open Login Behavior and Security on the instance or organisation login policy.
  2. Enable External IDP Allowed so users can choose federated sign-in.
Add a provider
Section titled “Add a provider”
  1. Go to Identity Providers on the instance or organisation.
  2. Pick a template (Google, Entra ID, generic OIDC, SAML SP, LDAP, and others) or use Generic OIDC / SAML Service Provider when no template exists.
  3. Complete the vendor-specific client IDs, secrets, and redirect URIs Zitadel displays.

Common template settings:

SettingPurpose
ScopesClaims requested from the external IdP (openid, profile, email, plus vendor-specific scopes)
Automatic creationCreate a Zitadel user on first external login when no account exists
Automatic updateRefresh profile fields from the IdP on each login
Account linkingAllow linking external identity to an existing Zitadel user
Instance default vs organisation IdP
Section titled “Instance default vs organisation IdP”
ScopeWhen to use
Instance defaultOne SSO strategy for all organisations in the workspace; central administration
OrganisationPer-customer or per-business-unit IdP; delegated administration

Supported provider guides

Section titled “Supported provider guides”

Zitadel publishes step-by-step guides for common providers. Use these when wiring your workspace (links open ZITADEL Docs):

For the full introduction and additional templates, see Let Users Login with Preferred Identity Provider on ZITADEL Docs.

SCIM provisioning

Section titled “SCIM provisioning”

Each workspace Zitadel instance supports inbound SCIM v2. Your corporate directory or HR system pushes user lifecycle events (create, update, deactivate) to Zitadel; Fontana does not require a separate SCIM endpoint in Flow.

Typical setup:

  1. Enable SCIM on the Zitadel organisation or project in the Zitadel Management Console and copy the SCIM endpoint URL and bearer token for your IdP (Entra ID, Okta, and others publish SCIM app templates for Zitadel).
  2. Map directory groups or attributes to Zitadel project roles so provisioned users receive the correct role grant before first login.
  3. On login (or SCIM-driven pre-provision), Flow projects the Zitadel role into Convex users.roleId (see Roles and RBAC). There are no per-user permission overrides in the app.
  4. Deprovisioning in the directory disables or removes the user in Zitadel; Flow enforces users.enabled so access ends without editing roles inside Admin.

Identity events from SCIM and sign-in feed the immutable security audit trail automatically. See Immutable audit trail.

For Zitadel SCIM configuration details, see SCIM provisioning on ZITADEL Docs.

MFA and session policy

Section titled “MFA and session policy”

MFA (TOTP and WebAuthn) is enforced through Zitadel login policy, independent of which IdP authenticated the user. Your organisation can require MFA for all users or specific login methods. WebAuthn requires a registrable domain over HTTPS on production auth hostnames; local development typically uses TOTP.

Section titled “Related documentation”