Single Sign-On (SSO): Architecture, Flows, and Practical Examples

Single Sign-On (SSO) lets a user authenticate once and then access many applications without logging in again each time. Instead of every app having its own login screen and password database, SSO centralizes authentication and delegates trust to an identity provider (IdP).

This note explains:

What SSO is and why it matters
The core architecture and components
How common protocols (SAML, OAuth2/OIDC) implement SSO
End-to-end flows with practical examples

1. Why Single Sign-On?

Without SSO:

Each app has its own login form and password store.
Users must remember multiple passwords; they reuse weak ones.
Onboarding/offboarding is painful (accounts in many systems).
Auditing and security policies are inconsistent.

With SSO:

Central authentication – one IdP knows who the user is.
Apps (called service providers or relying parties) delegate auth to the IdP.
Users log in once and get tokens/assertions that other apps can trust.
Access control and security policies are managed centrally.

Benefits:

Better user experience (fewer logins).
Stronger security (central MFA, password policies, account lockout).
Easier compliance and auditing.
Cleaner separation of concerns between auth and application logic.

2. SSO architecture: core building blocks

2.1 Actors

User / User agent – browser or mobile app.
Identity Provider (IdP) – central authority that authenticates users and issues identity information (e.g. Azure AD, Okta, Auth0, Keycloak).
Service Provider (SP) / Relying Party (RP) – application that relies on the IdP for auth (web app, API, SaaS product).

High-level view:

User  <---->  IdP (Identity Provider)
  \               ^
   \              |
    +-->  App A --+
    +-->  App B --+
    +-->  App C --+

2.2 Trust relationships

Before SSO works, each SP must trust the IdP:

They share keys/certificates to sign/verify tokens or assertions.
They agree on identifiers (client IDs, redirect URIs, audience values).
They agree on user attributes (email, username, roles, groups).

Once trust is configured, the IdP can assert “this user is X with attributes Y” and the SP will accept it.

3. Protocols used for SSO

SSO is a pattern; it is implemented with protocols:

SAML 2.0 – XML-based, common for enterprise SSO (especially older SaaS apps). Browser redirects carry SAML assertions.
OAuth 2.0 + OpenID Connect (OIDC) – JSON-based, common for modern web and mobile apps.
- OAuth 2.0: authorization (delegating access to APIs).
- OIDC: OAuth 2.0 plus identity layer (who the user is).

This article focuses on SAML and OIDC, as they are the most common for SSO.

4. Browser-based SSO: OIDC authorization code flow (modern pattern)

4.1 Components

Browser (user agent)
Web app (RP) – e.g. https://app.example.com
IdP / Authorization Server – e.g. https://login.example-idp.com

4.2 Flow (simplified)

User tries to access app
- Browser requests GET /dashboard at app.example.com.
- App sees no valid session and redirects to the IdP’s /authorize endpoint.
Redirect to IdP (login)
- Redirect URL contains:
  - client_id – identifies the app.
  - redirect_uri – where the IdP sends the user back.
  - response_type=code – authorization code flow.
  - scope=openid profile email – identity scopes.
  - state – CSRF protection.
  - nonce – protects against token replay.
User authenticates at IdP
- IdP shows login page (username/password, SSO to corporate AD, MFA, etc.).
- After successful login, IdP creates SSO session (cookie) for this browser.
IdP redirects back with code
- 302 redirect to redirect_uri with ?code=xyz&state=....
- Browser now hits the app’s redirect handler.
App exchanges code for tokens (back-channel)
- App server calls IdP’s /token endpoint with:
  - grant_type=authorization_code
  - code=xyz, redirect_uri, and client credentials (secret or private key).
- IdP responds with:
  - ID token (JWT) – who the user is.
  - Access token – for calling APIs.
  - Optional refresh token.
App validates ID token and creates session
- Verify signature, audience, issuer, expiry.
- Read user ID, email, groups/roles.
- Create an app session (e.g. secure cookie or server-side session).
- Redirect user to the original page (e.g. /dashboard).
SSO for other apps
- When the same browser visits App B, it redirects to IdP.
- IdP sees the existing SSO cookie and does not ask for credentials again; it immediately sends a new code/tokens back to App B.
- From the user’s perspective, they were logged into App B without another login screen.

This is SSO via OIDC: the browser holds a session with the IdP; each app trusts the IdP and uses tokens to identify the user.

5. SAML-based SSO (classic enterprise pattern)

5.1 High-level

SAML uses XML assertions instead of JWTs and is widely used between enterprises and SaaS vendors (e.g. SSO from corporate IdP into Salesforce).

Two common flows:

SP‑initiated SSO – user goes to app first; app redirects to IdP.
IdP‑initiated SSO – user starts from IdP portal; clicking an app tile posts a SAML response to the SP.

5.2 SP‑initiated SSO flow (simplified)

User accesses https://app.example-saas.com.
App (SP) sees user is not authenticated and sends a SAML AuthnRequest to IdP (via redirect).
Browser is redirected to IdP with the SAML request.
IdP authenticates user (maybe via corporate AD, MFA).
IdP generates a SAML assertion (XML, signed with IdP’s private key) containing user identity and attributes.
IdP posts the SAML response (HTML form auto-submitted) back to the SP’s Assertion Consumer Service (ACS) URL.
SP validates the signature and assertion (issuer, audience, expiry) and creates a local session for the user.

Subsequent apps (other SPs) repeat the same redirect → assertion → ACS flow but, because the user already has an IdP session, they won’t see the login page again.

6. SSO in microservices and APIs

For APIs / microservices, SSO typically uses OAuth2 + OIDC tokens:

Frontend (browser or mobile app) obtains an access token and ID token from the IdP.
It sends the access token as Authorization: Bearer <token> to backend APIs.
The APIs validate the token (signature, issuer, audience, expiry) and use claims to enforce authz (roles, scopes).

Patterns:

Gateway / API gateway (Kong, NGINX, Envoy, APIM) that:
- Validates tokens at the edge.
- Injects user identity/claims into headers for internal services.
- Centralizes auth logic and simplifies microservices.
Backend-for-frontend (BFF):
- BFF handles OIDC directly and issues its own short-lived session cookies to the browser.
- Reduces token exposure on the frontend and centralizes security logic.

7. Security considerations

Trust and keys
- Rotate signing certificates/keys; use JWKS or metadata documents for discovery.
- Validate all critical fields on tokens/assertions (iss, aud, exp, nbf).
Sessions and logout
- User has:
  - A session with the IdP (SSO cookie).
  - A session per app.
- Logout can be:
  - Local (only one app).
  - Single logout (SLO) – IdP tells all SPs to log out; support varies by protocol and vendor.
MFA and conditional access
- IdP centrally enforces multi-factor auth, device checks, network locations, risk-based policies, etc., so every SSO-integrated app benefits.
Least privilege
- Use scopes/roles in tokens; each app should only grant permissions needed for that user.
- Don’t over-stuff tokens with sensitive data; keep claims minimal.

8. Example: corporate SSO with Azure AD

Scenario: A company uses Azure AD as IdP with three apps:

Jira (SaaS) via SAML.
Internal portal (React + .NET) via OIDC.
API used by mobile apps via OAuth2.

Flows:

User opens Jira; Jira redirects to Azure AD SAML SSO.
- User logs in once; Azure AD sets SSO cookie and issues SAML assertion.
Later, user opens internal portal.
- Portal redirects to Azure AD /authorize (OIDC).
- Azure AD sees SSO cookie, skips login, issues ID token + access token.
Portal calls the internal API with the access token.
- API validates token, authorizes based on scopes and roles.

From the user’s view: one login, many apps. From ops view: one place (Azure AD) to manage accounts, MFA, password policies, and audit logs.

9. Summary

SSO centralizes authentication in an identity provider, letting users log in once and then access many apps.
It relies on trust relationships and protocols like SAML and OIDC to pass identity between IdP and apps.
Modern implementations use OAuth2/OIDC for web and mobile apps, while SAML remains common for enterprise SaaS.
APIs and microservices typically use access tokens (Bearer JWTs) validated at gateways or services.
Properly designed SSO improves security, UX, and manageability, but requires careful attention to trust, token validation, sessions, and logout flows.

quyennv.com