SSO

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

The Real-World Incident That Made This Famous

Understanding SSO became critical after multiple high-profile production incidents at major tech companies. When systems handle millions of users, even small misunderstandings about SSO can lead to cascading failures that cost millions in lost revenue and erode user trust. Companies like Netflix, Google, Amazon, and Meta have all invested heavily in mastering SSO because they learned the hard way that ignoring it leads to outages.

The key lesson from these incidents: SSO is not just a theoretical concept — it is a practical skill that separates engineers who build resilient systems from those who build fragile ones. Every major outage report from the past decade involves at least one SSO-related design decision that was either implemented incorrectly or overlooked entirely during the initial architecture review.

How Senior Engineers Think About This

Senior engineers approach SSO differently from textbook definitions. Instead of memorizing rules, they build mental models. They ask: "What problem does SSO solve? When does it fail? What are the alternatives?" This problem-first thinking leads to better design decisions because every system has unique constraints.

When evaluating SSO in a system design context, experienced engineers consider the failure modes first. What happens when this component goes down? How does the system degrade? Is the degradation graceful or catastrophic? These questions reveal more about your understanding than any textbook definition.

The key difference between junior and senior engineers when it comes to SSO: juniors focus on the happy path, while seniors design for what happens when things go wrong. They consider operational cost, team expertise, monitoring requirements, and how the decision will look six months from now when traffic has grown 10x.

Common Interview Mistakes

Mistake 1: Giving a textbook definition without context. Interviewers want to see you connect SSO to real systems and real problems. Instead of reciting definitions, explain when and why you would use SSO in the system you are designing.

Mistake 2: Not discussing trade-offs. Every design decision involving SSO has trade-offs. Discuss what you gain and what you give up. Acknowledge the downsides and explain why the benefits outweigh them for your specific use case.

Mistake 3: Overcomplicating the solution. Start with the simplest approach to SSO that meets the requirements, then add complexity only when justified. Many candidates jump to complex implementations when a simpler solution would work perfectly.

Production Checklist

• Define clear metrics for measuring the effectiveness of your SSO implementation
• Set up monitoring and alerting that specifically tracks SSO-related failures
• Document your SSO design decisions in Architecture Decision Records (ADRs)
• Test failure scenarios related to SSO in staging before production deployment
• Review and update your SSO implementation quarterly as system requirements evolve
• Train new team members on the specific SSO patterns used in your system
• Establish runbooks for common SSO-related incidents and recovery procedures

Practical Implementation for .NET Developers

In ASP.NET Core, use AddAuthentication().AddOpenIdConnect() for OIDC-based SSO. Configure the IdP's authority URL, client ID/secret, and callback paths. The middleware handles the entire OIDC flow — redirect, code exchange, token validation. For SAML, use the Sustainsys.Saml2 library or ITfoxtec.Identity.Saml2. For Azure AD specifically, AddMicrosoftIdentityWebApp() from Microsoft.Identity.Web provides a streamlined setup with token caching and graph API integration.

ASP.NET Core setup: Create a service class that encapsulates the logic, register it with dependency injection, and inject it into your controllers or minimal API endpoints. The built-in DI container handles lifecycle management.

Entity Framework Core: For database interactions, EF Core provides the ORM layer. Use migrations for schema management and raw SQL for performance-critical queries. Consider Dapper for read-heavy paths where EF Core overhead matters.

Azure integration: If deploying to Azure, leverage managed services — Azure Cache for Redis, Azure SQL, Azure Service Bus, Azure Cosmos DB. These eliminate operational overhead and provide built-in monitoring through Application Insights.

Testing: Use xUnit with Testcontainers for integration tests that spin up real databases in Docker. Mock external dependencies with NSubstitute. The WebApplicationFactory class lets you test your entire HTTP pipeline in-process.

Monitoring: Add Application Insights telemetry to track request latency, dependency calls, and custom metrics. Use structured logging with Serilog to make production debugging possible:

Log.Information("Processing {Operation} for {ResourceId}", operation, resourceId);

This gives you searchable, structured logs in Azure Monitor or Seq.