Clerk enterprise SSO: wire a SAML connection per org and enforce it

TL;DR: Enterprise customers bring their own identity provider. The setup is a handshake: Clerk generates an ACS URL and entity ID, the customer's IdP admin configures them, and you map the connection to the customer's organization and flip on enforcement. Open the dashboard Enterprise Connections section (or per-org: pick the organization, then its SSO connections). Add a SAML or OIDC connection and scope it to the customer's organization.

Enterprise SSO connections per organization

The order

1. Open the dashboard Enterprise Connections section (or per-org: pick the organization, then its SSO connections). Add a SAML or OIDC connection and scope it to the customer's organization. Each org can hold multiple connections; each connection covers one domain.

2. Clerk generates the ACS URL and entity ID for the connection. Hand these to the customer's IdP admin (Okta, Entra ID, Google Workspace) along with the attribute mapping you expect: email, first name, last name.

3. The customer configures their IdP side with those values and gives you their IdP metadata (SAML) or client credentials (OIDC) to paste back into Clerk.

4. Set the domain the connection enforces on. Clerk routes sign-ins with that email domain through the connection automatically.

5. Enable enforced SSO on the organization so members must use the IdP. Without enforcement, users can still sign in with other methods and your customer's IT policy is decoration.

6. New users from the matching domain auto-join through JIT provisioning. Test with a fresh test user from the customer's domain before announcing it done.

The traps

• A domain used for enterprise SSO cannot also be a verified domain for the same organization. They are distinct features: SSO is IdP-mandated auth, verified domains are auto-invite and auto-suggest without SSO. Pick one per domain per org.

• Managing connections needs the manage self-serve SSO system permission (org:sys_entconns:manage) on the role doing the setup.

• In custom sign-in flows the strategy name is enterprise_sso in current SDKs. Older code calling it saml will not match.

Checklist

• Test the full loop from a logged-out browser with a real customer-domain email, not just the IdP admin's account.

• Confirm JIT-provisioned users land in the right org with the right default role.

• Document the IdP metadata expiry for the customer. When their certificate rotates and nobody told you, logins break at 9am Monday.

When to use this

• This covers exactly what the title says: Clerk enterprise SSO.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Clerk; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Clerk behavior.

Verified against Clerk's enterprise connection model: connections scoped per organization, Clerk-generated ACS URL and entity ID for the IdP admin, domain-based routing with JIT provisioning, enforced SSO as a separate step, and the rule that an SSO domain cannot double as a verified domain for the same org.