Adding SSO to homegrown authentication: the enterprise control gap

At a glance

What this is: This is a developer-focused explainer on extending homegrown authentication with enterprise SSO, with Microsoft Entra ID used as the example IdP.

Why it matters: It matters because teams that own IAM, NHI, and lifecycle governance need to understand where custom authentication stops being safe, especially when federation, tenant routing, and session handling are added.

👉 Read Descope's walkthrough on adding SSO to homegrown authentication

Context

Homegrown authentication often starts with a simple email-and-password flow, but that model breaks down once enterprise customers expect SSO, tenant discovery, and policy-controlled federation. In practice, the problem is not just adding SAML or OIDC, but governing the full authentication lifecycle across tenants and identity providers.

For IAM teams, the key issue is control surface expansion. Once a custom auth stack starts handling metadata, login hints, redirect endpoints, and claim mapping, the organisation is operating an identity integration layer that must be designed, reviewed, and maintained like any other access path.

Key questions

Q: How should security teams add SSO to a homegrown authentication system without creating new risk?

A: Keep tenant routing, IdP selection, and claim handling on the backend, then validate the federated response before creating local sessions. Homegrown SSO becomes risky when the client influences federation choice or when authentication success is allowed to bypass application-level authorisation rules.

Q: What breaks when SSO is bolted onto a custom auth stack without governance?

A: Configuration drift is the usual failure mode. Certificates, metadata, redirect endpoints, and claim mappings change over time, and a custom stack can keep authenticating users while quietly diverging from the intended access model.

Q: Why do enterprise customers push homegrown apps toward SSO and federation?

A: Because enterprise access depends on central control, not just login success. Customers want their own identity provider, their own admin policies, and their own lifecycle oversight, which means the application must integrate with federation in a governed way.

Q: How do security teams know if their SSO implementation is actually safe?

A: Look for evidence that the backend owns IdP selection, federated sessions are validated before token issuance, and claim mappings are documented and tested. If those controls are implicit or scattered across code paths, the SSO design is fragile.

Technical breakdown

Tenant discovery and home realm routing in SSO

Home realm discovery is the process of determining which identity provider should authenticate a user, usually from email domain or tenant context. In a homegrown system, this logic often sits in backend code that maps user input to a tenant and then to a SAML or OIDC initiation flow. The risk is not the redirect itself, but the trust decision behind it. If the client can influence IdP selection, the organisation can create account confusion, broken federation, or policy bypass across tenants.

Practical implication: keep IdP selection server-side and treat tenant routing as a policy decision, not a frontend convenience.

SAML metadata, certificates, and redirect endpoints

Enterprise SSO introduces a lifecycle problem as much as a protocol problem. SAML integrations depend on entity IDs, ACS URLs, certificates, metadata exchange, and logout endpoints that must stay aligned across tenants and identity providers. When these values drift, authentication failures become hard to diagnose and security posture can degrade quietly. The same is true for custom attributes and claims, which must match the downstream application’s authorisation model and user lifecycle assumptions.

Practical implication: inventory SAML metadata, certificate expiry, and claim mappings as governed assets with ownership and renewal checks.

Session handoff after federation

A federated login does not end when the identity provider authenticates the user. The application still has to exchange the SAML response or authorization code for a local session, validate it, and decide how that session maps into existing application tokens. This is where custom auth designs often become brittle: a secure upstream login can still be undermined by weak local session handling, loose token issuance, or inconsistent route protection. Federation and session management must be designed together.

Practical implication: validate the external identity result before minting local tokens, and align session issuance with the application’s own access rules.

NHI Mgmt Group analysis

Homegrown authentication becomes an identity governance problem the moment it starts brokering enterprise SSO. The architecture is no longer a simple login form plus password check. It becomes a federation layer that must manage trust boundaries, tenant routing, and downstream session issuance with the same discipline used for any other access control plane.

SSO in custom applications exposes a control gap, not just a protocol gap. The hard part is not understanding SAML or OIDC syntax. The hard part is maintaining a consistent policy decision across IdP selection, claim mapping, logout, and post-authentication session creation. If those steps are handled inconsistently, the application can authenticate correctly while still authorising the wrong access pattern.

Tenant-aware login flows create governance expectations that many product teams are not prepared to own. Once different customers can authenticate through different identity providers, the organisation must manage metadata drift, certificate rotation, and tenant-specific endpoint changes as operational identity controls. That shifts the problem from feature development into lifecycle governance.

Homegrown SSO is sustainable only when identity boundaries are explicit. The application must know which decisions belong to the backend, which belong to the external IdP, and which belong to local session logic. Without that separation, enterprises inherit an authentication path that is easy to demo but difficult to govern.

Claim mapping is where enterprise authentication often stops being purely technical and becomes organisational. Email, groups, first name, last name, and domain-based routing all encode assumptions about who the user is and what access they should receive. The practitioner lesson is simple: if the claims model is not governed, the SSO flow is not governed.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, even though 92% say governance is critical to enterprise security.
• That gap is why teams should pair identity lifecycle discipline with the Ultimate Guide to NHIs as they extend authentication and access controls into federated and machine-led flows.

What this signals

Homegrown SSO is a reminder that identity architecture expands faster than most product teams expect. Once an application starts supporting enterprise federation, the programme inherits tenant lifecycle, metadata management, and session governance obligations that look a lot like broader IAM operations. Teams that treat SSO as a feature rather than an identity control will accumulate hidden support debt.

The next maturity step is to make federation decisions observable. Backend-owned tenant routing, documented claim mapping, and controlled session handoff create the audit trail IAM and security teams need when authentication spans multiple providers.

Credential and session boundaries should be evaluated together. Even when the source identity provider is well governed, local token issuance and route protection can become the weak link. That is why custom auth teams should review the full path from login initiation to session termination, not just the IdP handshake.

For practitioners

• Keep IdP selection server-side Resolve tenant and identity provider routing in backend logic, not in the client, so users cannot spoof which federation path they take. Treat home realm discovery as a policy-controlled step in the authentication flow.
• Track SAML metadata as governed configuration Maintain entity IDs, ACS URLs, certificates, and logout endpoints in a controlled inventory with ownership, expiry checks, and change validation. The main failure mode in enterprise SSO is configuration drift across tenants.
• Separate external authentication from local authorisation Validate the federation response, then issue local sessions only after the application has applied its own access rules. Do not let a successful IdP login automatically determine application access.
• Map claims to explicit access rules Define how email, group membership, and user attributes translate into tenant membership and route access before enabling SSO. Unreviewed claim mapping can turn federation into implicit privilege assignment.
• Review logout and session termination paths Verify that federated logout, local token invalidation, and callback handling behave consistently across tenants and providers. If sign-out is not governed, session persistence can outlive the intended trust boundary.

Key takeaways

• Custom authentication becomes an IAM governance issue once it must support enterprise SSO, because tenant routing and federation decisions shape access outcomes.
• The main operational risk is not the login protocol itself, but drift in metadata, certificates, claims, and local session handling.
• Teams should treat federation as a controlled identity boundary and verify that backend policy, not the client, determines who can authenticate and what access follows.

Key terms

• Home Realm Discovery: Home realm discovery is the process of identifying which identity provider should authenticate a user before login continues. In enterprise SSO, it usually happens through email domain, tenant context, or routing logic. The security concern is whether that decision is controlled by the backend and aligned with policy.
• SAML Metadata: SAML metadata is the configuration information that allows a service provider and identity provider to trust each other. It includes entity identifiers, endpoints, certificates, and binding details. In practice, metadata must be treated like governed configuration because expiry or drift can break authentication and weaken assurance.
• Session Handoff: Session handoff is the transition from external authentication to a local application session. After the identity provider validates the user, the application still has to decide how to issue, store, and validate its own session or token. This is where custom auth stacks often introduce security and governance gaps.
• Claim Mapping: Claim mapping is the process of translating identity provider attributes into application attributes or access decisions. Common examples include email, group membership, and user names. If claim mapping is not explicitly governed, federation can become an indirect privilege assignment mechanism rather than a controlled access path.

What's in the full article

Descope's full blog post covers the implementation detail this post intentionally leaves for the source:

• Step-by-step SAML configuration in Microsoft Entra ID and the matching Descope tenant settings.
• Example backend code for generating redirect URLs, handling callbacks, and exchanging SAML responses for sessions.
• Claim mapping details for attributes such as email, firstName, lastName, and groups.
• The full flow for protecting application routes after federation succeeds.

👉 Descope's full post shows the SAML setup, backend redirect logic, and session exchange flow.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.