--- source_url: "https://docs.descope.com/sso/multi-sso?utm_source=openai" title: "Multiple SSO Providers Per Tenant | Descope Documentation" mirrored_at: 2026-08-04T01:04:52.377Z host: docs.descope.com cited_in_42a: true mirror_canonical: "https://index.42a.ai/docs.descope.com/sso/multi-sso__q__utm_source_openai" --- > **Original source:** https://docs.descope.com/sso/multi-sso?utm_source=openai Guides and Tutorials Single Sign-On (SSO) Most tenants need one IdP. Some need several on the same tenant, for example Acme's corporate Okta plus a contractor Entra directory, or regional IdPs under one customer org. That is what this page covers: **multiple SSO configurations on one tenant**, each with its own `ssoId`. It is not the same as “each customer gets a tenant with one IdP” (that’s ordinary multi-tenant SSO). Use additional SSO configs when: - One customer org authenticates through more than one IdP - Different email domains under the same tenant must hit different IdPs - You want a separate [SCIM](https://docs.descope.com/management/tenant-management/scim#multi-tenant-and-multi-sso-architecture) pipeline per IdP - Admins should configure each connection in its own [SSO Setup Suite](https://docs.descope.com/auth-methods/sso/sso-setup-suite) link If every customer is a separate org with one IdP, create one tenant per customer instead. See the [B2B guide](https://docs.descope.com/b2b) and [SSO overview](https://docs.descope.com/auth-methods/sso). Every tenant has a **default** SSO configuration. You can add more profiles in the Console or via the Management API/SDK. Each additional profile has an `ssoId` you use when starting SSO, loading settings, or generating a Setup Suite link. ![An example of how to configure multiple SSO within a tenant in Descope's console.](https://docs.descope.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fmulti-sso-1.b7628de0.webp&w=3840&q=75) You can also generate a dedicated [SSO Setup Suite link](https://docs.descope.com/auth-methods/sso/sso-setup-suite#accessing-the-sso-setup-suite) per configuration (pass `ssoId` when generating the link). ![An example of how to configure multiple SSO within a tenant via Descope's SSO Setup Suite.](https://docs.descope.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fmulti-sso-2.d35a7451.webp&w=3840&q=75) ### [Domains on Each SSO Config](#domains-on-each-sso-config) Assign **SSO domains** on each configuration (not only on the tenant). Descope uses the user’s email domain to pick the matching connection when you start SSO with the tenant and don’t pass an `ssoId`. Example under tenant `Acme`: SSO config SSO domains IdP Default `acme.com` Acme Okta `contractors` `acme-contractors.com` Contractor Entra A user signing in as `alex@acme.com` is routed to Okta. A user signing in as `sam@acme-contractors.com` is routed to Entra. ### [Pass `ssoId` Explicitly](#pass-ssoid-explicitly) When domain routing isn’t enough (shared domains, picker in your UI, deep link to a specific IdP), pass the configuration id when you start SSO. **Backend SDK** (optional `sso_id` / `ssoId` on start, shown in [SSO with Backend SDKs](https://docs.descope.com/auth-methods/sso/with-sdks/backend)): ``` resp = descope_client.sso.start( tenant="acme-tenant-id", return_url="https://app.example.com/sso/callback", sso_id="contractors", # optional; omit to use domain routing / default ) ``` **Management SDK.** Load or delete a specific profile with `ssoId`: ``` const ssoSettings = await descopeClient.management.sso.loadSettings('tenantId', 'contractors'); ``` Full surface: [Configure SSO with SDKs](https://docs.descope.com/management/tenant-management/sso/sdks). **SSO Setup Suite embed.** Append `?ssoId=...` so the iframe opens that profile ([embed guide](https://docs.descope.com/sso/sso-setup-suite-embed)): ``` ``` ### [Tenant Slug / ID Still Applies](#tenant-slug--id-still-applies) You still identify the **tenant** first (SSO domain, tenant slug/ID, or flow `tenant` param). Multi-SSO then picks **which IdP inside that tenant**. See [Tenant identification](https://docs.descope.com/auth-methods/sso#tenant-identification-methods). [SCIM](https://docs.descope.com/management/tenant-management/scim) is tied to each SSO configuration, not only the tenant. Each IdP can have its own SCIM base URL and token under that profile. Group → role mapping on the SSO config applies to both SCIM and JIT for that connection. After a user signs in, `lastAuth.ssoId` holds the SSO configuration used for that login. You can branch the flow on it (see [dynamic keys](https://docs.descope.com/flows/dynamic-keys)). 1. Create the default SAML/OIDC connection on the tenant (Console or Setup Suite). 2. Add another SSO configuration and note its `ssoId`. 3. Put the right **SSO domains** on each config, or plan to pass `ssoId` from your app. 4. Map attributes and groups on each config ([SSO mapping](https://docs.descope.com/sso/sso-mapping)). 5. If you use SCIM, configure it under each SSO profile that needs directory sync. 6. Test each connection (Setup Suite test, or [Mock SAML](https://docs.descope.com/management/tenant-management/sso/mock-saml-testing) for a non-prod profile). 7. Ship start/exchange with the tenant id, and `ssoId` when domain routing isn’t enough. - [SSO overview](https://docs.descope.com/auth-methods/sso) - [SSO Setup Suite](https://docs.descope.com/auth-methods/sso/sso-setup-suite) - [Configure SSO (Management SDKs)](https://docs.descope.com/management/tenant-management/sso/sdks) - [SCIM multi-SSO](https://docs.descope.com/management/tenant-management/scim#multi-tenant-and-multi-sso-architecture) - [SSO troubleshooting](https://docs.descope.com/other-troubleshooting/sso-troubleshooting)