SSO & Authentication Design

Single Sign-On (SSO) is a mechanism that lets users access multiple services and applications with a single authentication. In enterprise environments where employees use dozens of systems, SSO is essential for reducing operational costs and improving security.

Why SSO Is Needed

When employees use 10 to 30 SaaS products such as Slack, Salesforce, GitHub, and Jira, managing separate passwords for each causes the following problems:

• Password reuse and weak passwords proliferate
• Security risk from forgetting to delete accounts of departed employees
• Help desk costs from “I forgot my password” requests

SSO centralizes authentication in a single Identity Provider (IdP). Each service (SP: Service Provider) relies on the IdP to vouch for authentication.

Core Authentication Protocols

OAuth 2.0

OAuth 2.0 is an authorization framework that allows one service to access resources from another. “Authorization” determines what is permitted, which is distinct from “authentication,” which determines who someone is.

Main flows:

Flow	Use case	Characteristics
Authorization Code Flow	Web apps	Most secure, recommended
Client Credentials Flow	Server-to-server	API integration without a user
Device Flow	Input-limited devices (TV, etc.)	Authenticate via a second device

OIDC (OpenID Connect)

OIDC (OpenID Connect) adds an authentication layer on top of OAuth 2.0. While OAuth 2.0 handles authorization only, OIDC issues an ID token (in JWT format) that proves who authenticated. OIDC is the current standard for modern SSO systems.

SAML 2.0

SAML (Security Assertion Markup Language) 2.0 is an XML-based authentication and authorization specification from 2005. It remains widely used in large enterprise on-premise systems and legacy SaaS. Okta and Microsoft Entra ID (formerly Azure AD) fully support SAML.

OIDC Authentication Flow

sequenceDiagram
    participant U as User
    participant App as Application (SP)
    participant IdP as Identity Provider

    U->>App: Access
    App->>U: Redirect to IdP
    U->>IdP: Login (password or MFA)
    IdP->>App: Return authorization code
    App->>IdP: Exchange code for access token + ID token
    IdP->>App: Issue tokens
    App->>U: Login complete, session established

OAuth 2.0 vs OIDC vs SAML Comparison

Item	OAuth 2.0	OIDC	SAML 2.0
Purpose	Authorization (resource access)	Authentication + authorization	Authentication + authorization
Data format	JSON	JWT (JSON)	XML
Year introduced	2012	2014	2005
Mobile support	Good	Good	Difficult
Enterprise adoption	High	High (growing)	Very high
Implementation complexity	Low–medium	Low–medium	High

JWT Token Structure

JWT (JSON Web Token) is the token format used in OIDC and OAuth. It consists of three Base64URL-encoded segments joined by dots (.):

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIn0.signature
      ↑ Header              ↑ Payload             ↑ Signature

The payload contains claims such as:

{
  "sub": "user123",
  "email": "alice@example.com",
  "exp": 1747123456,
  "iat": 1747119856,
  "iss": "https://auth.example.com"
}

Always validate the exp (expiration) claim and reject expired tokens.

Applying SSO to AI Systems

When integrating LLM services such as the Claude API or OpenAI API into an enterprise environment, the following design is recommended:

1. Apply SSO at the API gateway: Users authenticate with SSO to the gateway, and the gateway calls the LLM API
2. Scope service accounts narrowly: Grant only the minimum necessary permissions to AI service accounts
3. Propagate JWT claims: Forward JWT claims to the AI service to enforce access control based on user attributes

Session Management

Item	Recommended setting
Access token lifetime	15–60 minutes
Refresh token lifetime	1–30 days
Idle session timeout	30–60 minutes
Logout	Invalidate session at the IdP as well (Single Logout)

Enterprise IdP Options

IdP	Highlights	Supported protocols
Okta	SaaS-focused, rich integrations	OIDC, SAML, OAuth 2.0
Microsoft Entra ID	Deep Microsoft product integration	OIDC, SAML, OAuth 2.0
Google Workspace	Google product integration	OIDC, SAML
Auth0 (Okta)	Developer-friendly, highly customizable	OIDC, SAML, OAuth 2.0

Common Implementation Mistakes

• Storing tokens in localStorage: Tokens can be stolen via XSS. Store them in httpOnly cookies instead
• Not validating token expiration: Expired tokens are accepted without a check
• Using ID tokens as API access tokens: ID tokens are for authentication only. Use access tokens for API calls
• Not implementing Single Logout: Logging out of the IdP leaves active sessions in each SP

Frequently Asked Questions

Q: SAML vs OIDC — which should I choose?

OIDC is recommended for new systems. It is JSON/JWT-based, making mobile and SPA integration straightforward. Choose SAML when connecting to legacy systems that only support SAML. Using an IdP that supports both protocols (such as Okta or Microsoft Entra ID) makes future migration easier.

Q: How do I test SSO locally?

Running Keycloak locally is a common approach. It can be started with Docker: docker run -p 8080:8080 quay.io/keycloak/keycloak:latest start-dev. Okta and Auth0 also offer free Developer Editions suitable for development and testing.

Q: How does MFA (multi-factor authentication) combine with SSO?

MFA is implemented on the IdP side. The IdP requests MFA as part of the SAML or OIDC flow, so individual services (SPs) do not need their own MFA implementations. This is one of the primary benefits of combining SSO with MFA.

See the references for the external specifications and background sources used on this page.[1][2][3][4]

References

1. OAuth 2.0 RFC 6749
2. OpenID Connect Core 1.0
3. Okta Developer Documentation
4. Microsoft Entra ID Documentation