Single Sign-On (SSO)

About

Single Sign-On (SSO) is an authentication mechanism that enables users to log in once and gain access to multiple related applications without being asked to log in again for each of them.

Instead of each application having its own login system, authentication is centralized through a shared system called an Identity Provider (IdP).

Example: App and Food Website

Consider a banking app and a partnered food delivery website. When a user logs into the banking app, they are authenticated by a central identity provider. Later, if they visit the food website (also integrated with the same identity provider), they are automatically recognized and logged in — no need to enter the username or password again.

SSO Flow

1. User logs in to the main app

   • The app redirects the login request to an Identity Provider (IdP).

   • The user enters credentials.

   • The IdP authenticates the user and creates a session.

2. Token is issued

   • The IdP generates an access token and possibly an ID token (e.g., JWT).

   • These tokens contain claims about the user (username, email, roles, etc.).

3. App stores the token

   • The app stores the token temporarily (e.g., in memory or secure local storage).

4. User clicks link to the food website

   • The user is redirected to the food website.

   • The app passes the token (either through query param, cookie, or header).

5. Food website validates the token

   • The food website checks if the token is valid.

   • It may call the IdP or verify the JWT signature locally.

   • If valid, the user is authenticated without logging in again.

Key Components

Component	Description
Identity Provider (IdP)	A centralized authentication system that all apps trust (e.g., Keycloak, Okta, Azure AD)
Service Provider (SP)	The app or website that delegates authentication to the IdP (e.g., your banking app or food site)
Token (JWT/Opaque)	A digital proof that the user has been authenticated
Protocol	The standard used to communicate authentication: OAuth2.0, OpenID Connect (OIDC), or SAML

Common Protocols Used

Protocol	Purpose
OAuth2.0	Authorization protocol, issues access tokens
OpenID Connect (OIDC)	Built on top of OAuth2, used for Authentication (includes ID token)
SAML 2.0	XML-based protocol, often used in enterprise SSO (e.g., for HR systems)

Token Types

• Access Token is used to access APIs and must be presented in every request (usually in the Authorization: Bearer header).

• ID Token is only used in OpenID Connect and meant for identity — not for accessing APIs.

• Refresh Token is kept secure and never exposed to frontend apps in public clients like browsers.

Token Type	Purpose	Contains	Used By	Lifespan
Access Token	Grants access to protected resources	User ID, scopes/permissions, expiry, audience	Resource servers (APIs, microservices)	Short-lived (minutes)
ID Token	Verifies the identity of the authenticated user	User info (email, name, username), issued time, expiry	Client applications (e.g., frontend, app)	Short-lived (minutes)
Refresh Token	Issues a new access token without re-login	Client ID, user ID, token expiry	Authorization server (IdP)	Long-lived (hours/days)

Token Propagation in Microservices

When using SSO in microservices:

• The token is forwarded between services (usually HTTP headers).

• Each service must validate the token.

• Centralized token verification reduces duplicated logic.

For example:

• App → API Gateway → Order Service → Delivery Service

• The access token must be passed through each layer.

Security Considerations

1. Token Security

   • Use short-lived access tokens and refresh tokens.

   • Store tokens securely (e.g., not in local storage for web apps).

   • Tokens must be signed (e.g., using RSA or HMAC) and verified on each request.

2. Token Expiration & Revocation

   • Tokens should expire quickly to limit impact if stolen.

   • Include a revocation mechanism (e.g., token blacklist or introspection endpoint).

3. Logout

   • Implement Single Logout (SLO) to end sessions across all systems when user logs out from one.

   • This is harder in practice and needs careful handling via the IdP.

4. CSRF & CORS

   • Handle cross-origin scenarios properly (especially when passing tokens between domains).

   • Use secure cookies and CSRF tokens where needed.

5. TLS Everywhere

   • All communication between client, IdP, and service providers must use HTTPS.

Common Tools for Implementing SSO

Tool	Purpose
Keycloak	Open-source identity provider with OAuth2, OIDC, SAML support
Okta	Cloud-based IdP for enterprise SSO
Spring Security + OAuth2 Client	Common in Java Spring Boot applications
Azure AD / Google Identity	Common external IdPs for SSO
API Gateway (e.g., Kong, NGINX)	Used for token validation and enforcement

Advantages

• Improved user experience: One login for many services.

• Centralized authentication: Easier to enforce security policies.

• Reduced password fatigue: Users don’t have to remember multiple credentials.

• Auditability and logging: Track access across all systems from one place.

• Faster onboarding/offboarding: Add or remove access from a central system.