# Self-serve SSO

By default, enterprise SSO connections are configured by your team within the Clerk Dashboard. For every enterprise customer that needs SSO, someone on your side has to create the connection, exchange metadata with the customer's IT admin, test the connection, and activate it. As your enterprise motion scales, this becomes a bottleneck.

Self-serve SSO lets you delegate that configuration directly to your customers' IT admins. When you enable it for an Organization, a **Security** tab appears in that Organization's [<OrganizationProfile />](https://clerk.com/docs/reference/components/organization/organization-profile.md), where an Organization [admin](https://clerk.com/docs/guides/organizations/control-access/roles-and-permissions.md) can set up and manage the connection end-to-end: adding domains, choosing an identity provider, exchanging metadata, and testing the connection.

The connection is scoped to the Organization it's configured in, and behaves like any other enterprise connection once it's live.

> Self-serve SSO is currently scoped to [Clerk Organizations](https://clerk.com/docs/guides/organizations/overview.md) and is only available through the **Security** tab of `<OrganizationProfile />`. Your application must use Organizations to offer it.

## Requirements

For an admin to configure a connection, the following must be true:

- Your application uses [Clerk Organizations](https://clerk.com/docs/guides/organizations/overview.md).
- [Self-serve SSO is enabled for the Organization](#enable-self-serve-sso) in the Clerk Dashboard.
- The signed-in user is a member of the Organization with the `org:sys_entconns:manage` [System Permission](https://clerk.com/docs/guides/organizations/control-access/roles-and-permissions.md#system-permissions). This permission ships with the default [**Admin**](https://clerk.com/docs/guides/organizations/control-access/roles-and-permissions.md#default-roles) Role. If you've defined custom Roles, add the Permission to any Role that should be able to manage enterprise connections. For more information, refer to the [Roles and Permissions guide](https://clerk.com/docs/guides/organizations/control-access/roles-and-permissions.md).

## Enable self-serve SSO

Self-serve SSO is enabled per Organization. Until you enable it for an Organization, the **Security** tab will not appear in that Organization's `<OrganizationProfile />`.

1. In the Clerk Dashboard, navigate to the [**Organizations**](https://dashboard.clerk.com/~/organizations) page.
2. Select the Organization you want to enable self-serve SSO for.
3. Open the **Settings** tab.
4. In the **Organization permissions** section, enable **Allow this organization to set up enterprise SSO**.

Once enabled, the **Security** tab becomes available in that Organization's [<OrganizationProfile />](https://clerk.com/docs/reference/components/organization/organization-profile.md) for admins. If your application already renders `<OrganizationProfile />`, including through the [<OrganizationSwitcher />](https://clerk.com/docs/reference/components/organization/organization-switcher.md) component, the flow surfaces there automatically. If not, render the component on a page where Organization admins can reach it.

## How the flow works

When an admin opens the **Security** tab in `<OrganizationProfile />`, they're guided through the following steps:

1. **Domains** — The admin adds one or more domains to claim for the connection and verifies [ownership](https://clerk.com/docs/guides/organizations/domain-verification.md#domain-ownership) of each by publishing a DNS `TXT` record that Clerk checks.
2. **Connection** — The admin selects an IdP and provides the protocol-specific configuration. IdP setup instructions are embedded inline, so you don't need to author or maintain your own walkthroughs. Self-serve SSO supports Okta, Google Workspace, Microsoft Entra ID, and **custom SAML**.
3. **Test** — The admin runs a test sign-in to confirm the connection works end-to-end.
4. **Activate** — Once the test passes, the admin activates the connection.

## Next steps

Once a connection is created, it behaves like any other Clerk enterprise connection. Users with matching email domains can sign in via the configured IdP. To learn more, refer to:

- [Authentication flows](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/authentication-flows.md)
- [Account linking](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/account-linking.md)
- [Just-in-Time (JIT) provisioning](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/jit-provisioning.md)
- [Directory Sync (SCIM)](https://clerk.com/docs/guides/configure/auth-strategies/enterprise-connections/directory-sync.md)

---

## Sitemap

[Overview of all docs pages](https://clerk.com/docs/llms.txt)