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