Multiple Enterprise SSO Connections per Organization
An organization in PropelAuth can now connect to more than one identity provider. Employees can log in through Okta, contractors through Entra ID, a newly acquired team through Google Workspace, and all of them end up in the same organization. SAML, OIDC, and SCIM are all supported, and each connection is configured and maintained separately.
Why one connection stops being enough
Most organizations map cleanly to one identity provider, but plenty don't. The requests tend to sound like this:
- "Our full-time employees are in Okta, but our contractors are all in Entra ID. Can both groups log in to the same workspace?"
- "We just acquired a company and they're still on their own Google Workspace. We can't migrate them for another year."
- "Our team in Germany is on a different IdP than the rest of us. Is there a way for them to log in without us setting up a whole separate account?"
With a single connection per org, each of these cases needed a workaround. You could create a second organization and have the customer manage two of everything, ask them to consolidate identity providers before they roll out your product, or hand out password logins as exceptions. None of those are what the customer asked for.
How it works
The feature is opt-in and scoped at two levels.
Turn it on for your project. Go to the Enterprise SSO/SCIM page in your PropelAuth dashboard and toggle on Multiple SSO Connections. This makes the option available but doesn't change any organization on its own.
Enable it per organization. Open an organization in the dashboard, go to its Enterprise SSO tab, and turn on Allow multiple SSO connections?. Then click Add Connection for each identity provider the customer needs. Each connection gets an internal name (your customer won't see it) and one or more email domains.
Send your customer a setup link. Once a connection is added, PropelAuth generates an Enterprise SSO Setup Page link for it. The link is tied to that one connection, so you can give the Okta link to the team that manages employees and the Entra link to whoever runs the contractor directory, and neither one can modify the other's setup. The setup flow itself is the same one PropelAuth already uses: step-by-step guides for Google, Okta, Entra, OneLogin, JumpCloud, Ping, Duo, Rippling, or a generic SAML/OIDC provider, along with attribute mapping.
Routing users to the right IdP
Domains are what make this work. Every connection is tied to one or more email domains, and PropelAuth uses them to pick the right identity provider when a user logs in.
Say Acme has two connections: acmeinc.com on a SAML connection with Okta, and contractor.org on an OIDC connection with Entra ID.
- If your login page identifies organizations by domain,
john@acmeinc.comenters their email and is sent to Okta.jane@contractor.orgis sent to Entra. - If you identify organizations by name, the user enters "Acme Inc" as usual. Since that org has more than one connection, PropelAuth also asks for their email address and uses the domain to choose the connection.
Users don't need to know which connection they belong to in either case.
What your customers can manage themselves
Once a connection is set up, your customer's admins can maintain it from the hosted organization settings page if two things are true:
- Their role includes the Enterprise SSO permission.
- Their email domain matches the connection they're editing. An admin with an
acmeinc.comaddress can update the Okta SAML certificate but can't touch thecontractor.orgconnection.
From that page they can update the connection's configuration, give it a customer-facing nickname so their users can tell connections apart, and configure SCIM for the connection if you've enabled it.
Separately, each connection has a display name that shows up in your PropelAuth dashboard. That one is for your team and isn't shown to customers.
What changes for developers
If you've built on top of PropelAuth's Enterprise SSO APIs, there are a few things to know before you enable this for an organization.
A new endpoint lists an org's connections. GET /api/backend/v1/sso_connections/{ORG_ID} returns each connection with its connection_id, SSO method, IdP type, display name, email domains, test-mode status, and whether SCIM is configured.
SCIM group APIs take a connection_id. Fetch Org SCIM Groups and Fetch Org SCIM Group now require a connection_id query parameter for orgs with multiple connections. You can get the ID from the endpoint above.
Direct redirects may need an extra parameter. If you send users straight to {AUTH_URL}/api/fe/v3/login/saml with only org_id or org_name, an org with multiple connections will return an ambiguous_results error. Add domain or email so PropelAuth knows which connection to use:
{AUTH_URL}/api/fe/v3/login/saml?org_id=1e01ac72-42c1-484a-8115-94341b036194&domain=acmeinc.comOne more thing to be aware of: once multiple connections are enabled for an org, new connections (including the first one) can only be created through a setup link, not from the hosted pages. Existing connections can still be edited there as described above.
Nothing else changes
Your authorization code, org-scoped queries, and role checks all keep working as before. Which identity provider a user came through is still an implementation detail of how that organization manages its members, the same way SAML versus OIDC always has been.
Get started
Enable Multiple SSO Connections from the Enterprise SSO/SCIM page in your dashboard, then turn it on for the organizations that need it.
The full documentation, including API details and the domain routing rules, is here. If you have a customer with an unusual identity setup and aren't sure how to model it, email support@propelauth.com and we'll help you work through it.
