┌───────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ 📄 shadcn/directory/clerk/clerk-docs/guides/configure/auth-strategies/enterprise-connections/overview │ └───────────────────────────────────────────────────────────────────────────────────────────────────────┘
╔══════════════════════════════════════════════════════════════════════════════════════════════╗
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
Enterprise Single Sign-On (SSO) allows users to sign in seamlessly using their Identity Provider (IdP) credentials (e.g.,Azure AD, Okta, or Google Workspace) and have their user data synchronized with Clerk. Clerk supports multiple protocols for implementing Enterprise SSO, including SAML and OIDC. Learn more about the process in the guides on authentication flows and account linking.
Clerk supports Enterprise SSO via the SAML protocol, enabling you to create authentication strategies for an IdP. The following IdPs are supported: Microsoft Azure AD, Google Workspace, and Okta Workforce. However, you can also integrate with any other IdP that supports the SAML protocol.
Authenticating via SAML SSO requires the user's email address domain to match the exact domain the SAML connection has been configured with. By default, subdomains are not supported. For example, a user with the email address john@sales.example.com wouldn't be able to use a SAML connection with the example.com domain to authenticate.
To configure subdomains for a SAML connection:
[!NOTE] To enable the Allow subdomains option, your SAML connection domain must be an eTLD+1.
Clerk ensures that security critical nonces are passed only to allowlisted URLs when the SSO flow is completed in native browsers or webviews. For maximum security in your production instances, you need to allowlist your custom redirect URLs via the Clerk Dashboard or the Clerk Backend API.
To allowlist a redirect URL via the Clerk Dashboard:
Clerk supports Enterprise SSO via the OpenID Connect (OIDC) protocol, either through EASIE or by integrating with any OIDC-compatible provider.
EASIE SSO is a way for applications to provide enterprise-grade SSO through a multi-tenant OpenID provider. It is designed to be an easier alternative to SAML SSO.
The following IdPs are supported: Google Workspace and Microsoft Entra ID. For development instances, Clerk uses preconfigured shared credentials and redirect URIs—no other configuration is needed. For production instances, you must provide custom credentials. Follow the steps outlined in the guides to complete the setup:
Clerk prevents users linked to deprovisioned accounts in the OpenID provider from accessing the app.
Before creating a new session token for an EASIE user, Clerk verifies whether the user has been deprovisioned from their OpenID provider (e.g., suspended or deleted in Google Workspace, or deleted in Microsoft Entra). This verification process might involve a delay of up to 10 minutes. If deprovisioning is detected, Clerk revokes that user's existing sessions and responds to any requests for a new session token with a 401 Unauthorized error.
It is ultimately the app's responsibility to handle this unauthenticated state and display something appropriate to the user. For example, Next.js apps using auth.protect() will automatically redirect the user to the sign-in page.
The primary security difference between EASIE SSO and SAML SSO is that EASIE depends on a multi-tenant identity provider, while SAML depends on a single-tenant identity provider. Relying on a multi-tenant provider increases the risk that a user from one tenant will mistakenly be granted access to the resources of another tenant. While Clerk implements measures to address this risk, apps that require single-tenant IdPs should opt for SAML.
For more information, see the EASIE docs.
Yes, multiple identifiers (such as email, username, or other attributes) can be configured and used for SAML and OIDC connections. However, for EASIE connections, there can only be one identifier or authentication method.
By default, additional identifiers are disabled for new connections. To enable multiple identifiers for a SAML or OIDC connection:
Yes, Enterprise SSO will work for your existing users as well! If you enable SAML or EASIE, any existing users with an email address that matches the SAML or EASIE connection domain will have to authenticate on the IdP side and an Enterprise account will be linked to their existing account.
Once the user returns from the IdP, they will need to complete additional authentication factors. This is useful if you want to add extra factors beyond what your IdP supports or if your IdP doesn’t support them. This feature is optional and can be disabled if not needed.
The users will not be deleted, so your app will not break. However, they will need to use another sign-in option such as password or email codes to authenticate themselves moving forward.
Yes, for SAML only. Clerk supports both Service Provider-initiated (SP-initiated) and Identity Provider-initiated (IdP-initiated) SSO flows. For more information, see the authentication flows guide.
For development instances, Enterprise connections are always free but limited to a maximum of 25.
Production instances require the Pro plan and the Enhanced Authentication Add-on. Please see pricing{{ target: '_blank' }} for more information.
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
╚══════════════════════════════════════════════════════════════════════════════════════════════╝