A typical enterprise employee uses dozens of applications: email, HR systems, project management tools, internal wikis, expense tracking, and more.

Without single sign-on, that employee would need to remember separate credentials for each application and log in to each one individually. This creates friction for users and a nightmare for IT departments managing password resets and access control.

Single Sign-On (SSO) solves this problem. Users authenticate once and gain access to multiple applications without re-entering credentials. When an employee logs in to their corporate identity provider in the morning, they can access Slack, Jira, Salesforce, and internal tools seamlessly.

1. What is Single Sign-On?

Single Sign-On (SSO) is an authentication scheme that allows users to access multiple independent applications with a single set of credentials. The user authenticates once, and that authentication is recognized across all connected systems.

The key insight is separation of concerns: instead of every application managing its own authentication, a dedicated identity system handles authentication centrally, and applications trust that system.

Benefits of SOO

For Users

For Organizations

For Developers

2. Core Concepts

Before diving into how SSO works, let us understand the key players.

Key Roles

Trust Relationships

The foundation of SSO is trust. Service Providers trust the Identity Provider to correctly authenticate users. This trust is established through:

When an SP receives an authentication assertion from an IdP, it trusts that assertion because:

Authentication vs Authorization

SSO primarily handles authentication (who is this user?), but it often includes authorization information (what can this user do?).

The IdP authenticates the user and can pass attributes (like group memberships) that SPs use for authorization decisions.

3. How SSO Works

Let us walk through what happens when a user accesses an application in an SSO environment.

The SSO Flow (SP-Initiated)

The most common flow starts when a user tries to access an application (Service Provider) without an existing session.

Let us break down each step:

Step 1-2: User Requests Access

The user navigates to . Jira checks for an existing session. Finding none, it needs to authenticate the user.

Step 3-4: Redirect to Identity Provider

Jira does not handle authentication itself. Instead, it redirects the user's browser to the Identity Provider (Okta) with an authentication request. This request includes:

Step 5: User Authentication (If Needed)

The IdP checks if the user already has an active IdP session (maybe they logged into another app earlier). If not, the IdP presents its login page. The user enters credentials and completes MFA. The IdP validates everything and creates an IdP session.

Step 6-8: Token Generation and Delivery

The IdP generates an authentication token containing verified information about the user. This token is sent back to Jira through the user's browser (via redirect or form post).

Step 9-11: Token Validation and Access

Jira receives the token and validates it:

If valid, Jira creates its own session for the user and grants access.

The Magic: Subsequent Logins

Here is where SSO shines. The user now clicks a link to Confluence (another SP):

Because the user already has an active session at the IdP (from logging into Jira), steps 5a-5d are skipped entirely. The user is authenticated to Confluence without entering credentials again.

4. SSO Protocols: SAML vs OpenID Connect

Two protocols dominate the SSO landscape: SAML and OpenID Connect (OIDC). Understanding when to use each is important for system design.

SAML 2.0

Security Assertion Markup Language uses XML-based assertions to exchange authentication data.

Characteristics:

Best for:

OpenID Connect (OIDC)

OpenID Connect is an identity layer built on OAuth 2.0, using JSON-based tokens (JWTs).

Characteristics:

Best for:

Protocol Comparison

Which Protocol to Choose?

Rule of thumb: Use OpenID Connect unless you have a specific reason to use SAML (legacy requirements, enterprise mandates).

5. Session Management

SSO involves multiple sessions that must be coordinated. Understanding session lifecycle is critical for security and user experience.

Session Types

IdP Session: Established when the user authenticates with the Identity Provider. This is the "master" session that enables SSO across applications.

SP Sessions: Each Service Provider maintains its own session. These are created when the user first accesses each SP and the IdP vouches for them.

Session Lifecycle

Session Duration Considerations

The IdP session duration affects security and user experience:

Best practice: Use shorter IdP sessions with refresh mechanisms. Require step-up authentication for sensitive operations.

Single Logout (SLO)

When a user logs out, ideally they should be logged out of all applications. This is Single Logout.

SLO Challenges:

Practical approach: Implement SLO where possible, but design systems to handle partial logout gracefully. Use short SP session durations as a fallback.

6. SSO Architecture Patterns

Different architectures serve different needs. Choose based on your scale, requirements, and constraints.

Pattern 1: Centralized IdP

A single Identity Provider handles all authentication.

Best for: Small to medium organizations, startups, SaaS platforms.

Pattern 2: Federated Identity

Multiple IdPs trust each other, allowing users from different organizations to access shared resources.

Best for: B2B applications, partner integrations, consortiums (like higher education).

Pattern 3: Hub and Spoke

A central authentication hub sits between users and applications, federating with multiple upstream IdPs.

Best for: Multi-tenant SaaS with enterprise customers, applications supporting both social and enterprise login.

Pattern 4: Microservices with Shared Authentication

In a microservices architecture, a central authentication service handles SSO while services verify tokens locally.

Best for: Cloud-native applications, microservices architectures.

7. Security Considerations

SSO centralizes authentication, which is powerful but also creates concentrated risk. Security must be thoughtful.

Authentication Strength

Since SSO provides access to many applications, the authentication at the IdP must be strong.

Token Security

The tokens exchanged in SSO must be protected:

Signature Validation: Always verify cryptographic signatures. Never trust unsigned tokens.

Audience Validation: Verify the token was meant for your application. A token for App A should not work at App B.

Expiration Enforcement: Reject expired tokens. Do not add excessive clock skew tolerance.

Replay Prevention: Use nonces (OIDC) or track used assertion IDs (SAML) to prevent token reuse.

Transport Security: All SSO traffic must use HTTPS.

Common Attack Vectors

IdP as Critical Infrastructure

The Identity Provider becomes a high-value target. Protect it accordingly:

8. Implementing SSO

When designing an SSO solution, consider these decisions and trade-offs.

Build vs Buy

Recommendation: Use a managed IdP unless you have specific requirements (air-gapped environments, extreme customization needs) and the expertise to operate identity infrastructure securely.

Integration Patterns

For Web Applications

For APIs

User Experience Considerations

Login Page Redirect: Users expect to be redirected to a familiar login page. Make sure the IdP login page is branded and trustworthy.

Deep Linking: When users access a specific page before authentication, redirect them back to that page after login, not the home page.

Session Persistence: Decide whether to persist IdP sessions across browser restarts. Longer sessions improve UX but reduce security.

Logout Clarity: Make logout behavior clear. Users should understand whether logging out of one app logs them out everywhere.

Handling Edge Cases

IdP Unavailability: What happens when the IdP is down?

Clock Skew: Servers with different clocks cause token validation failures

Token Revocation: How to invalidate a compromised user's access?

Summary

Single Sign-On transforms authentication from a per-application concern into a centralized, manageable system. The key concepts to remember:

Core Components:

Protocols:

Session Management:

Architecture Patterns:

Security Essentials:

SSO is foundational to modern application security. Whether you are building a SaaS platform, enterprise application suite, or consumer product with social login, understanding SSO patterns helps you design systems that are both secure and user-friendly.