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 establishedOAuth 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 ↑ SignatureThe 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:
- Apply SSO at the API gateway: Users authenticate with SSO to the gateway, and the gateway calls the LLM API
- Scope service accounts narrowly: Grant only the minimum necessary permissions to AI service accounts
- 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
httpOnlycookies 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]
Summary
Centralize authentication through a suitable identity provider, use current protocols, and combine SSO with layered account protections.
This article is a general information summary and is not legal advice. Confirm practical decisions with a qualified specialist.