Single Sign-On

Single sign-on (SSO) enables users to authenticate once and access multiple applications without re-entering credentials. SSO is one of the most impactful IAM capabilities — it reduces password fatigue, eliminates credential sprawl, decreases IT helpdesk password-reset volume by 30-50%, and provides a centralised authentication audit trail.

However, SSO also introduces a single point of failure: if the SSO provider is unavailable or compromised, all federated applications are affected.

How SSO Works — The Core Flow

SSO relies on a trust relationship between the Service Provider (SP) — the application the user wants to access — and the Identity Provider (IdP) — the system that authenticates the user and asserts their identity.

User → Service Provider (SP) → Redirect to Identity Provider (IdP) → User authenticates → IdP issues assertion → Redirect to SP → SP grants access

SP-Initiated SSO (Unsolicited)

The user attempts to access a protected resource at the SP. The SP redirects the user to the IdP for authentication. After successful authentication, the IdP redirects the user back to the SP with an authentication assertion.

Common for: Enterprise applications where users navigate directly to the application URL.

IdP-Initiated SSO

The user authenticates at the IdP portal and then clicks on an application tile to launch the application. The IdP generates an assertion and sends it (typically via HTTP POST or redirect) to the SP.

Common for: Employee portal dashboards (Okta dashboard, Microsoft My Apps, Google Workspace).

SSO Protocols — Detailed Comparison

SAML 2.0 — Deep Dive

SAML 2.0 (Security Assertion Markup Language) is the dominant enterprise SSO protocol. It uses XML-based assertions to communicate authentication and authorization data between the IdP and SP.

SAML Assertions

A SAML assertion is an XML document that contains statements about a user:

• Authentication statement — When and how the user authenticated (method, timestamp, session index)
• Attribute statement — User attributes (email, roles, department, manager)
• Authorization decision statement — Whether the user is permitted to access a specific resource

SAML Binding Types

SAML Key Concepts

Entity ID — A globally unique identifier for the SP or IdP (typically a URI). ACS (Assertion Consumer Service) URL — The SP endpoint that receives and processes SAML assertions. Audience restriction — The SAML assertion includes an audience field that limits which SP can consume it. Name ID — The identifier that the SP uses to recognise the user (email, persistent ID, transient ID). SessionNotOnOrAfter — The timestamp after which the SAML assertion expires.

OpenID Connect (OIDC) — Deep Dive

OIDC is a modern authentication protocol built on OAuth 2.0. It adds an identity layer that enables the client application to verify the user’s identity and obtain basic profile information.

OIDC Flow — Authorization Code with PKCE

OIDC Token Types

OIDC Claims

The ID Token contains standard and custom claims in its JSON payload:

{
  "iss": "https://accounts.example.com",
  "sub": "984751234567890",
  "aud": "client-app-123",
  "exp": 1718234567,
  "iat": 1718230967,
  "nonce": "n-0S6_WzA2Mj",
  "email": "user@example.com",
  "email_verified": true,
  "name": "Jane Doe",
  "preferred_username": "jane.doe"
}

Enterprise SSO Deployment Patterns

Hub-and-Spoke (IdP-Centric)

All applications connect to a central IdP. The IdP handles authentication for all applications.

Pros: Centralised control, consistent policy enforcement, single audit trail. Cons: Single point of failure, IdP vendor lock-in, all traffic routed through IdP. Best for: Organisations with a single primary IdP (Okta, Azure AD, Ping).

Federated Mesh

Applications connect to multiple IdPs with established trust relationships. An authentication event at one IdP can be accepted by applications connected to other IdPs.

Pros: Flexibility, supports M&A scenarios, no single dependency. Cons: Complex trust management, inconsistent policy enforcement. Best for: Large enterprises, post-merger identity integration, multi-cloud environments.

Gateway-Based SSO

An SSO gateway/reverse proxy sits in front of applications and handles authentication centrally. Applications behind the gateway receive authenticated requests with identity headers.

Pros: No application changes required, consistent for legacy apps. Cons: Gateway is a bottleneck, header-based auth can be spoofed if misconfigured. Best for: Legacy applications that cannot support SAML or OIDC natively.

SSO Security Considerations

Key Takeaways

• SSO enables users to authenticate once and access multiple applications, reducing password fatigue and helpdesk volume by 30-50%
• SAML 2.0 (XML-based, enterprise-focused) and OpenID Connect (JSON-based, modern) are the dominant SSO protocols — OIDC is preferred for mobile/SPA and greenfield deployments
• SP-initiated SSO (user goes to app first) and IdP-initiated SSO (user starts at IdP portal) serve different use cases
• OIDC adds identity assertion via the ID Token (JWT) on top of OAuth 2.0’s delegated authorization, with the Authorization Code + PKCE flow as the recommended pattern
• Enterprise SSO deployment patterns include hub-and-spoke (centralised), federated mesh (flexible), and gateway-based (legacy app support)
• SSO introduces a critical single point of failure — the IdP must be deployed for high availability with geographic redundancy
• Security risks include IdP compromise, assertion injection, session hijacking, SSO outages, and shadow SSO — each requires specific mitigations