Single Sign-On: SAML, OpenID Connect and Enterprise Login

Single Sign-On (SSO) lets users log in once and access multiple applications without re-entering credentials. You log into Google and automatically get access to Gmail, Drive, YouTube, and Calendar. SSO is implemented using SAML 2.0 (enterprise, XML-based) or OpenID Connect (modern, JSON-based on top of OAuth 2.0). For enterprises, SSO is non-negotiable — it centralizes identity management, improves security through a single authentication point, and eliminates the risk of users creating weak passwords for dozens of apps.

Why This Matters

Enterprise customers expect SSO — it is often a checkbox requirement for B2B SaaS deals. Without SSO, employees maintain separate credentials for every application, leading to password fatigue, weaker passwords, and security incidents. With SSO, the IT team manages identity in one place, enforces MFA centrally, and can instantly revoke access to all applications when an employee leaves. In system design, SSO appears in any enterprise-facing architecture question.

The Building Blocks

• Identity Provider (IdP): The trusted authority that authenticates users: Okta, Azure AD, Google Workspace. The IdP stores credentials, enforces MFA, and issues tokens/assertions to service providers.
• Service Provider (SP): The application that trusts the IdP. When a user accesses the SP, it redirects to the IdP for authentication, receives a signed assertion, and creates a local session.
• SAML 2.0: XML-based enterprise standard. The IdP returns a signed XML assertion containing user attributes. Widely used in enterprise but complex to implement and debug.
• OpenID Connect (OIDC): JSON-based identity layer on top of OAuth 2.0. Returns a JWT ID token with user claims. Simpler than SAML and preferred for modern applications.
• Session Management: After SSO login, each application maintains its own session. Single Logout (SLO) propagates logout to all connected applications — harder to implement than single login.

Under the Hood

In the OIDC flow: the user visits App A, which redirects to the IdP's /authorize endpoint. The IdP authenticates the user (checking for an existing IdP session), then redirects back to App A with an authorization code. App A exchanges the code for an ID token (JWT with user claims) and an access token. The user is now logged in to App A.

When the user visits App B, the same redirect happens. But this time, the IdP already has an active session (from the App A login), so it skips the login prompt and immediately redirects back to App B with a new code. The user experiences instant access without re-entering credentials — this is the "single" in SSO.

The critical challenge is session synchronization. If the user logs out of the IdP, all application sessions should be invalidated. OIDC supports this via back-channel logout: the IdP sends a logout token to each registered application, which invalidates the local session. In practice, many applications use short-lived sessions (15-30 min) and re-validate with the IdP on expiry, providing "eventually consistent" logout.

How Companies Actually Do This

Okta is the largest dedicated identity platform, handling SSO for 17,000+ organizations. They support SAML, OIDC, and WS-Federation for backward compatibility with legacy enterprise systems.

Google Workspace provides SSO for all Google applications. Users log in once and seamlessly access Gmail, Drive, Calendar, Meet, and third-party apps integrated via OIDC or SAML.

Microsoft Azure AD handles SSO for millions of enterprises. The Entra ID platform supports SAML, OIDC, and legacy protocols, enabling SSO across Microsoft 365, Azure, and thousands of SaaS apps.

Common Pitfalls

1. Not implementing Single Logout — users assume logging out of one app logs them out of everything, but without SLO their sessions in other apps remain active
2. Trusting unsigned SAML assertions — the signature on the SAML response prevents tampering, and skipping verification opens the door to forged authentication
3. Not handling IdP downtime — if the IdP is unreachable, all SSO-dependent applications become inaccessible. Consider cached sessions or graceful degradation.

Interview Questions Worth Practicing

1. How would you add SSO to an existing multi-application platform?
2. What are the tradeoffs between SAML and OpenID Connect for enterprise SSO?
3. How do you handle Single Logout across multiple applications?

The Tradeoffs

• SAML vs OIDC: SAML is the enterprise standard with broad IdP support but uses verbose XML and is harder to debug. OIDC uses JSON/JWT, is developer-friendly, and works well for mobile/SPA.
• Centralized Identity vs Autonomy: SSO centralizes auth management (easier security, one MFA policy) but creates a dependency. If the IdP goes down, nothing works.
• Long Sessions vs Frequent Re-auth: Long-lived SSO sessions improve UX but widen the attack window if a session is compromised. Short sessions are more secure but force frequent re-authentication.

How to Explain This in an Interview

Here is how I would explain SSO in a system design interview:

SSO lets users log in once to access multiple applications. I would implement it using OIDC because it is modern, JSON-based, and works well with SPAs and mobile apps. The architecture has an Identity Provider (Okta, Azure AD) that stores credentials and enforces MFA. When a user visits any of our applications, it redirects to the IdP. If the IdP already has a session (user logged in via another app), it skips the login prompt and returns an ID token immediately. Each application maintains its own session but trusts the IdP for identity. For logout, I would implement back-channel logout — the IdP notifies all applications to invalidate their sessions. The main tradeoff is the IdP becoming a single point of failure, so I would choose a highly available IdP (Okta/Azure AD) and cache sessions locally for short-term resilience.

Related Topics

• Authentication
• Authorization
• RBAC
• API Gateway

Original DosiBridge notes for Single Sign-On: SAML, OpenID Connect and Enterprise Login

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Single Sign-On: SAML, OpenID Connect and Enterprise Login is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Contract Evolution: For Single Sign-On: SAML, OpenID Connect and Enterprise Login, decide the contract evolution before choosing tools; otherwise the design looks clean but fails when sso changes.
• Idempotency: For Single Sign-On: SAML, OpenID Connect and Enterprise Login, decide the idempotency before choosing tools; otherwise the design looks clean but fails when sso changes.
• Pagination: For Single Sign-On: SAML, OpenID Connect and Enterprise Login, decide the pagination before choosing tools; otherwise the design looks clean but fails when sso changes.
• Error Shape: For Single Sign-On: SAML, OpenID Connect and Enterprise Login, decide the error shape before choosing tools; otherwise the design looks clean but fails when sso changes.
• Consumer Compatibility: For Single Sign-On: SAML, OpenID Connect and Enterprise Login, decide the consumer compatibility before choosing tools; otherwise the design looks clean but fails when sso changes.

Production review question

If a team adopts Single Sign-On: SAML, OpenID Connect and Enterprise Login, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track sso health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Single Sign-On: SAML, OpenID Connect and Enterprise Login, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.