What is the difference between using separate identity projects and using a shared session proxy across domains?

What the architecture choice changes in practice

Separate identity projects split the trust boundary. Each domain gets its own configuration, user pool, and policy shape, so local requirements can be handled cleanly without bleeding into adjacent domains. That improves isolation and makes ownership clearer, but it also means users, sessions, and operational controls are not naturally shared across domains.

A shared session proxy takes the opposite approach, it centralises the identity flow and then normalises session state at the edge. That can make multiple domains feel like one coherent experience, especially when applications need consistent cookies, headers, or routing decisions. The cost is that the proxy becomes part of the security boundary for every domain it fronts, so routing, token handling, and session lifetime must be designed very deliberately.

For a practitioner, the key difference is whether you want identity logic to be domain-local or edge-central. Domain-local designs reduce cross-domain coupling, while edge-central designs reduce duplication and user friction. The trade-off is not abstract, it shows up in policy drift, incident blast radius, and how much trust you place in the component that rewrites or forwards session context.

Where each model tends to fit better

Separate identity projects usually fit when domains have different compliance needs, different account populations, or different lifecycle rules. In those cases, forcing one shared flow can create awkward exceptions, especially if one domain needs stricter access review, different assurance, or a distinct recovery path. Isolation also helps when teams need autonomy and want to avoid accidental policy coupling.

A shared session proxy is more attractive when the business need is a unified front door across related domains. It works best when the main problem is consistency, not segregation, and when the domains can tolerate shared handling of session semantics. That makes it useful for portal-style experiences, but it is a weaker fit when domains should fail independently or when a compromise in one path should not influence another.

• Use separate projects when the priority is boundary clarity, local governance, and domain-specific control.
• Use a shared proxy when the priority is user continuity, centralised session handling, and reduced integration overhead.
• Treat the proxy as a high-value control plane component if it mediates authentication state for more than one domain.

One useful way to think about the choice is whether a shared failure mode is acceptable. If the answer is no, separate projects are safer. If the answer is yes but only with strong operational discipline, the shared proxy can be efficient, provided it is monitored and tightly change-controlled.

What can go wrong when the boundary is too shared

The main risk with a shared session proxy is that it concentrates trust. If session rewriting, header propagation, or routing logic is wrong, the error can affect every domain behind it. That creates a broader failure domain than isolated projects, and it can also make debugging harder because the symptom may appear in one application while the root cause sits in the shared edge layer.

Separate projects reduce that coupling, but they can create their own problems through inconsistency. Teams may drift into slightly different login experiences, timeout rules, or logout behaviour, and users feel that fragmentation immediately. Over time, that can also complicate operations because each project develops its own exceptions, which makes governance less uniform even if the boundaries are cleaner.

Shared session handling can also obscure ownership. If several domains rely on one proxy but no one team owns the full request path, small misconfigurations can linger. For that reason, it is important to know exactly where authentication state is created, transformed, and destroyed, and who is accountable for each transition.

Practitioner Guidance

What to verify: Confirm whether the domains truly need shared user state, or only a shared front end. If the domains have different access rules, recovery requirements, or audit expectations, separate projects usually give you cleaner control than retrofitting exceptions into one proxy.

Decision rule: If a session issue at the edge could affect multiple business domains at once, treat the shared proxy as a critical control and harden its routing, cookie scope, and change process accordingly. If that central blast radius is unacceptable, favour separation even if it costs more in user convenience.

Practitioner takeaway: This is fundamentally a boundary decision, not just an implementation preference, so optimise for the failure mode you are willing to inherit, not only for the login experience you want users to see.

Related resources from NHI Mgmt Group

• What is the difference between patching a vulnerability and reducing identity blast radius?
• What is the difference between embedding certification reviews in a service management platform and using a separate identity governance portal?
• What is the difference between identity analytics and access policy enforcement in campus identity governance?
• How should security teams manage session continuity when the same application needs to work across multiple domains?