Single Sign-On (SSO)

In an enterprise environment, users access dozens of independent software systems daily (e.g. email, HR portals, ticketing queues, and database dashboards). Requiring separate usernames and passwords for each system degrades the user experience and increases credential management overhead. Single Sign-On (SSO) solves this by allowing users to authenticate once with a central Identity Provider (IdP) and access multiple independent Service Providers (SPs) without re-logging in.

1. Learning Objectives

• Understand the core problem of credential fatigue in distributed networks.
• Differentiate between an Identity Provider (IdP) and a Service Provider (SP).
• Trace the steps of the SAML 2.0 Web Browser SSO profile flow.
• Compare XML-based SAML assertions with JSON-based OpenID Connect tokens.
• Explain the mechanics of Single Logout (SLO) across active sessions.
• Implement an SSO ticket validation and single logout simulator in Java, Python, and C++.

2. Prerequisites

Before learning about SSO, ensure you understand:

• Cookies & Session Domains: How browser cookies isolate states by host domain.
• OAuth 2.0 & OpenID Connect: Basic authorization code exchanges.
• Asymmetric Encryption: Public/Private key pairs and digital signatures.

3. Why This Topic Matters

Single Sign-On is the gold standard for enterprise access management.

Without SSO, if an employee leaves a company, the IT operations team must manually log into dozens of independent dashboards to delete that employee's user accounts. If they forget even one account, the ex-employee maintains access to sensitive company resources.

SSO architectures solve these security and administrative problems:

• Centralized Provisioning: Disabling a user in the central IdP immediately revokes their access to all downstream applications.
• Fewer Passwords: Users only need to memorize one strong master password, reducing password fatigue.
• Security Compliance: Enables security teams to enforce global policies, such as Multi-Factor Authentication (MFA), at a single central point.

4. Real-world Analogy

Think of visiting an Amusement Park:

When you arrive at the park, you do not pay separate cash values at each individual roller coaster and water slide.

The Ticket Booth (Identity Provider): Checks your ID and cash, and attaches a secure Wristband (SSO Token) to your arm.

The Roller Coaster (Service Provider): The ride attendants do not ask for your ID or credentials. They simply check your wristband. If it is valid and untampered with, they let you board the ride immediately.

5. Core Concepts

• Identity Provider (IdP): The central authority that stores user credentials and authenticates users (e.g. Active Directory, Okta, Ping Identity).
• Service Provider (SP): The downstream application that relies on the IdP to verify user identities (e.g. Salesforce, Slack, Zoom).
• SAML (Security Assertion Markup Language): An XML-based protocol widely used in enterprise environments. It uses digital signatures to pass assertions between the IdP and SPs.
• OIDC (OpenID Connect): A modern, JSON-based identity protocol built on top of OAuth 2.0, standard for web and mobile apps.
• Single Logout (SLO): A mechanism that automatically terminates active user sessions across all service providers when the user logs out of the central IdP.
• IdP-Initiated vs. SP-Initiated SSO:
  • SP-Initiated: The user navigates to the application, which detects they are unauthenticated and redirects them to the IdP login page.
  • IdP-Initiated: The user logs into the IdP dashboard first (e.g. Okta Portal) and clicks an application icon, which logs them into the app directly.

6. Visualizations

Service Provider-Initiated SSO Flow

Single Logout (SLO) Architecture

7. How It Works Step-by-Step

Federated SSO Login Steps

1. User Access: The user navigates to a service provider (e.g. http://company.slack.com).
2. Redirect generation: Slack detects the user lacks a local session. It generates a signed SAML request (or OIDC request) and redirects the user to the IdP (http://auth.company.com).
3. Central Login: The user logs in at the IdP using their master credentials. The IdP sets a session cookie on the user's browser for auth.company.com.
4. Assertion Generation: The IdP generates an XML/JSON assertion containing the user's details (e.g. email=alice@company.com) and signs it using the IdP's private key.
5. Redirect Handback: The IdP redirects the user back to the Slack redirect URI, passing the signed assertion.
6. Signature Validation: Slack reads the assertion and validates the signature using the IdP's public key. Slack then creates a local session cookie for company.slack.com and grants access.
7. Accessing a Second Site: The user navigates to company.zoom.us. Zoom redirects them to the IdP. The IdP detects the user's active session cookie, skips the login form, and redirects the user back to Zoom with a new signed assertion instantly.

8. Internal Architecture

SSO federation relies on cryptographic trusts and redirection bridges:

• Cryptographic Trust Exchange: During initial setup, the SP and IdP exchange public keys. The SP trusts that any token signed by the IdP's private key is authentic.
• User Session Cache: The IdP maintains a database of active user session keys and the list of SPs each user has logged into during their current session.
• Backchannel vs. Frontchannel Logout:
  • Frontchannel (Iframe): The IdP loads hidden iframes in the user's browser pointing to each SP's logout URL, prompting the browser to clear cookies for those domains.
  • Backchannel (API): The IdP makes direct server-to-server API calls to all registered SPs to invalidate the user's session tokens, which is more reliable than browser-based methods.

9. Request Lifecycle

Let's trace a Single Logout request:

1. Logout Trigger: A user clicks "Log Out" in the central company portal.
2. IdP Session Invalidation: The IdP terminates the user's central session and deletes the session cookie.
3. Federated Logout Routing: The IdP looks up the active SP database for that user (e.g. logged into Slack and Zoom).
4. Downstream Invalidation: The IdP sends a backchannel request to Slack and Zoom: POST /logout { "user_id": "alice" }.
5. Session Cleared: Slack and Zoom invalidate Alice's session tokens in their databases, completing the logout process.

10. Deep Dive

SAML 2.0 vs. OpenID Connect (OIDC) Comparison

Metric	SAML 2.0	OpenID Connect (OIDC)
Data Serialization	XML format.	JSON / JWT format.
Transport Layer	HTTP POST / Redirect binds (heavy payloads).	Lightweight REST / API headers.
Mobile Support	Poor (requires browser redirects, hard to parse in native apps).	Excellent (native support for mobile app integrations).
Security Signatures	XML Signature (XMLDSig).	JSON Web Signature (JWS).

11. Production Examples

• Okta: The leading enterprise Identity-as-a-Service (IDaaS) platform, providing centralized user directories, SSO, and Multi-Factor Authentication.
• Microsoft Active Directory Federation Services (ADFS): Standard in enterprise Windows environments, providing SAML SSO for on-premise and cloud apps.
• Keycloak: An open-source identity and access management solution that supports SAML 2.0 and OIDC out of the box.

12. Advantages

• Improved User Experience: Users log in once to access all company tools.
• Centralized Security Control: Security teams can manage access permissions and enforce MFA policies from a single dashboard.
• Reduced Password Risks: Minimizes the number of passwords users need to remember, reducing password fatigue and reuse.

13. Limitations

• Single Point of Failure (SPOF): If the central IdP goes offline, users cannot log in to any company applications.
• High-Value Target: A breach of the IdP database compromises credentials and access tokens for all connected downstream systems.
• Complexity of Single Logout: Managing clean logouts across multiple independent domains is complex and often fails due to network or browser cookie issues.

14. Trade-offs

• SAML vs. OIDC: SAML 2.0 is mature, feature-rich, and standard in enterprise settings, but XML parsing is complex and CPU-heavy. OIDC is lightweight, developer-friendly, and ideal for mobile and API integrations, but lacks some of SAML's advanced enterprise features (such as attribute queries).
• Frontchannel vs. Backchannel Logout: Frontchannel logout uses the user's browser (iframes) to clear cookies for each SP domain, which is simple but fails if the user closes their browser early. Backchannel logout uses server-to-server API calls, which is highly reliable but requires secure communication paths between all servers.

15. Performance Considerations

• Deploy High-Availability IdP Clusters: The IdP processes authentication requests for all services. Run the IdP in highly available clusters across multiple regions to prevent performance bottlenecks.
• Cache Public Signing Keys: Service providers should cache the IdP's public keys locally to verify token signatures without querying the IdP for every request.

16. Failure Scenarios

• Signing Key Expiration Outage: If the IdP rotates its private signing key but a service provider fails to update its public key cache, the SP will reject all new authentication tokens, locking out users.
  Mitigation: Automate key rotation using JWKS endpoints, and configure the SP to fetch the new public key if verification fails.
• Replay Attack Exploits: An attacker intercepts a valid SAML assertion or OIDC token and sends it to the SP to gain unauthorized access.
  Mitigation: Include unique one-time use tokens (nonces), verify client audiences, and set short expiration windows (e.g. 5 minutes) on assertion tickets.

17. Best Practices

• Enforce Multi-Factor Authentication (MFA) at the central IdP to secure all connected systems.
• Use OIDC for new web and mobile applications, and SAML for legacy enterprise integrations.
• Include a one-time token (nonce) and expiration timestamp in all assertions to prevent replay attacks.

18. Common Mistakes

• Failing to implement Single Logout, leaving users logged into downstream apps after they log out of the central portal.
• Failing to validate the audience claim (aud) in tokens, allowing tokens issued for one app to be reused on another.
• Using weak cryptographic keys or failing to rotate them regularly, increasing vulnerability to attacks.

19. Implementation (Federated SSO and Single Logout)

Below is a complete implementation of a Single Sign-On and Single Logout simulator in Java, Python, and C++. The simulator models a central Identity Provider (IdP) issuing signed tickets, two virtual Service Providers (SPs) validating tickets, and a backchannel Single Logout (SLO) workflow.

20. Interview Questions & Answers

Q1. Explain the difference between SP-Initiated and IdP-Initiated SSO.

Answer:

• In SP-Initiated SSO, the user navigates directly to the application (the Service Provider, e.g. Slack). The SP detects the user is unauthenticated and redirects them to the Identity Provider (IdP) with an authentication request.
• In IdP-Initiated SSO, the user logs into the central identity portal first (e.g. their Okta dashboard). They click on the Slack icon inside the portal, which redirects them to Slack with a signed assertion, logging them in directly.

Q2. What is Single Logout (SLO) and what are the main implementation patterns?

Answer: Single Logout terminates all active user sessions across all service providers automatically when the user logs out of the central IdP. Implementation patterns include:

• Frontchannel Logout (Browser-based): The IdP loads hidden iframes in the user's browser pointing to each SP's logout URL. The browser clears session cookies for each domain. This can fail if the user closes the window early or if the browser blocks cross-domain cookies.
• Backchannel Logout (Server-based): The IdP makes direct server-to-server HTTP POST requests to each SP's logout endpoint, invalidating user session tokens. This is highly reliable but requires secure, open communication paths between all servers.

Q3. Why is SAML 2.0 still preferred over OpenID Connect in legacy corporate enterprise settings?

Answer: SAML 2.0 has been the enterprise standard since 2005. It supports advanced enterprise-grade identity features that OIDC lacks, such as attribute queries (allowing the SP to query the IdP for specific user profile fields on demand) and XML encryption, which protects sensitive data fields before they are sent over the browser.

21. Practice Exercises

• Exercise 1 (Easy): Trace a diagram showing the request redirect loop when a user logs in to a portal via SP-Initiated SSO.
• Exercise 2 (Medium): Modify the Python IdentityProvider implementation to support dynamic ticket lifespans. Reduce ticket lifetimes to 2 seconds and verify that validation fails if a client waits too long.
• Exercise 3 (Hard): Write a Python module simulating frontchannel iframe logout. Render a list of HTML iframe tags pointing to registered service providers to clear their cookies.

22. Challenge Problem

The Third-Party Cookie Deprecation Challenge: You operate an enterprise portal that implements SSO across 5 independent websites using hidden iframes to sync session states.

Modern browsers (Chrome, Safari) block third-party cookies by default, preventing iframes from reading or writing cookies for other domains. As a result, users are forced to log in separately to each of the 5 websites.

• Propose a cookie-free session synchronization architecture that does not rely on third-party cookies or iframes.
• Draw a diagram showing how you would use OpenID Connect (OIDC) backchannel session synchronization and client-side web storage (LocalStorage) to maintain login states.
• Explain how to handle session logouts securely across all 5 websites without browser cookie access.

23. Summary

Single Sign-On is an essential enterprise security and usability pattern. It allows users to authenticate once with a central Identity Provider (IdP) and access multiple independent Service Providers (SPs) without re-logging in. Implementing federated SSO protocols like SAML or OIDC, combined with backchannel Single Logout (SLO), simplifies user management and strengthens security.

24. Cheat Sheet

Feature	SAML 2.0	OpenID Connect (OIDC)
Token Payload	XML Assertions.	JSON Web Tokens (JWT).
Transport Method	HTTP Redirects / POST bindings.	REST API headers (HTTP Bearer).
Logout Support	SAML Single Logout (SLO).	OIDC Back-Channel/Front-Channel Logout.
Ideal Ecosystem	Legacy corporate networks / Active Directory.	Modern web, mobile, and API SaaS platforms.

25. Quiz

26. Further Reading

• OASIS Security Services (SAML) Technical Committee Wiki.
• OIDC Back-Channel Logout 1.0 Specification.
• Real-World Single Sign-On — Keycloak developer resources.

27. Next Lesson Preview

SSO tokens must be encrypted when transmitted over the public network. In the next lesson, we will look at SSL, TLS & mTLS—the cryptographic protocols that secure transport layers in distributed systems.