**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.