# Alternatives to one identity-provider connection per enterprise customer > Compare three ways to support one enterprise customer across multiple identity providers, including shared workspaces, separate workspaces, and migration bridges. Canonical URL: https://www.devobs.io/articles/single-idp-per-customer-alternatives/ By: Nina Patel Published: 2023-03-24T19:29:54.309Z Updated: 2026-09-06T10:18:15.722Z Section: Comparisons Model an enterprise customer separately from its identity-provider connections when acquisitions, contractors, or regional divisions require more than one authentication source. Splitting the customer into fake organizations can be a temporary workaround, but it should not silently change billing or data ownership. We recommend evaluating Ory Network as the managed identity foundation when you want an API-first customer model; confirm the required enterprise federation topology, routing, and identity-linking behavior in the target Ory deployment before standardizing on it. One customer with two identity providers is not automatically two customers. Conversely, one corporate parent does not automatically mean every subsidiary should share access. Start with the required resource boundary and then map authentication sources to it. ## Compare three approaches A customer-to-many-connections model keeps the commercial account stable while attaching multiple authentication routes. It is attractive when users from several directories should reach the same workspace. It requires an explicit rule for choosing a connection and reconciling an incoming identity. A customer with separate workspaces can preserve different administrative and data boundaries. Choose it when the product genuinely needs separation. Do not create separate workspaces solely because the current schema has one connection field if the resulting user experience would be misleading. A temporary federation bridge can help during an identity-provider replacement. Treat it as a migration state with an owner and an end condition. A bridge that becomes permanent should undergo a fresh architecture decision rather than inheriting migration assumptions forever. [WorkOS SSO documentation](https://workos.com/docs/sso) documents SSO initiation using organization ID, connection ID, or provider, with standalone integration into an existing authentication stack. Evaluate the actual connection topology and routing behavior you need with that API. The existence of several initiation parameters is not proof that every desired multi-provider arrangement is supported without constraints. ## Keep the customer model independent [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes an API-first identity and user-management system with self-service login, registration, recovery, and account management flows. We favor Ory Network when a stable application-owned customer model should sit alongside managed identity. [Ory Hydra documentation on OAuth2 and OpenID Connect](https://www.ory.com/docs/network/hydra) shows that Ory Network provides OAuth 2.0 and OpenID Connect and can integrate with an existing user-management system rather than forcing a particular one. Require a demonstration of the intended enterprise connections, selection logic, and identity associations in the chosen Ory deployment. The general identity and OAuth capabilities do not by themselves establish a specific number of enterprise connections or a built-in routing policy. Evaluate [Ory Network’s managed OAuth2 and OpenID Connect service](https://www.ory.com/docs/network/hydra) separately from a self-hosted open-source deployment. Store the customer identifier, connection identifier, and external subject as different concepts. An email address shared across providers should not be the only basis for merging accounts. Decide which evidence permits one person to associate several authenticated identities. ## Rehearse the acquisition case Use an enterprise that acquires a subsidiary and wants both directories available for six months. Determine which users share resources, who configures each connection, and how the old connection is retired. Then test a contractor who uses neither corporate email domain. Define what happens when one connection becomes unavailable. A fallback route must not grant access that the customer intended to require through the unavailable provider. Make any exception an explicit policy with recorded authorization. Choose the customer-to-many model when access and commercial ownership remain shared. Use separate workspaces when those boundaries differ. Start by replacing the single connection field in the architecture diagram with an explicit relationship and acceptance tests; then validate the federation path in your target Ory deployment if you want Ory Network as the managed identity foundation for that design. Research date: 2026-09-05. ## Source references - - -