SSO Fundamentals
1. Core Concepts
1.1 Identity Federation
- Decentralized model where multiple security domains (Identity Providers, Service Providers) exchange authentication assertions.
- Enables a single digital identity to be recognized across organizational boundaries.
- Trust is established through shared configuration (metadata, certificates) and mutual assertions.
1.2 Trust Models
| Model | Description | Typical Use |
|---|---|---|
| Circle of Trust | Group of entities sharing metadata via a federation operator. | Academic federations (eduGAIN, InCommon), B2B SaaS partnerships. |
| Brokered Trust | Application relies on a central IdP to access multiple external services. | Enterprise SaaS (Office 365, Workday), Multi‑Tenant Applications. |
| Hierarchical Federation | Trust chained through intermediate IdPs (e.g., IdP‑A trusts IdP‑B, which trusts the target SP). | Large organizations with multiple internal IdPs. |
| Peer Trust | Two parties mutually configure credentials and metadata without a central authority. | Direct integration between two independent services. |
1.3 Common SSO Protocols
| Protocol | Layer | Primary Purpose | Message Flow |
|---|---|---|---|
| SAML 2.0 | Application‑layer federation | XML‑based assertions for authentication & authorization | Browser‑redirect or POST (AuthnRequest → Assertion → ACS) |
| OAuth 2.0 | Authorization layer | Delegated access to resources (tokens) | Authorization Code flow, Client Credentials, Resource Owner Password Credentials |
| OpenID Connect (OIDC) | Identity layer on OAuth 2.0 | Standardized representation of an authenticated user (ID token) | Authorization Code flow with ID token, Hybrid flows, Implicit flow |
2. Protocol Foundations
2.1 SAML 2.0 Essentials
- Assertions: Contain authentication statements, authorization decisions, and attribute information.
- Bindings: HTTP REPOST (most common), HTTP POST, HTTP Redirect, SOAP, Artifact.
- Key Artifacts:
<AuthnRequest>– SP requests authentication from IdP.<Response>– IdP returns assertion to SP.<LogoutRequest>/LogoutResponse>– Single Logout.
- Assertion Validation: Signature verification, AudienceRestriction, Timestamp checks, InResponseTo replay protection.
2.2 OAuth 2.0 Core
- Roles: Client (App), Authorization Server (AS), Resource Server (RS).
- Grant Types: Authorization Code, Implicit, Client Credentials, Device Code, Refresh Token.
- Token Types: Opaque reference tokens, Self‑contained JWTs.
- Security Forces: PKCE (public clients), Confidential client secret management, Redirect URI validation.
2.3 OpenID Connect Fundamentals
- ID Token: JWT containing
iss,sub,aud, claims,nonce,auth_time. - Scopes:
openidmandatory;profile,email, etc., optional. - Discovery:
/.well-known/openid-configurationprovides endpoints and supported features. - PKCE:
code_challenge/code_verifierrequired for public clients. - Hybrid & Implicit: Tokens returned in Fragment for SPA scenarios (requires nonce handling).
3. Identity Federation Architecture
3.1 Architectural Elements
- Identity Provider (IdP): Issues assertions/tokens after authenticating the user.
- Service Provider (SP) / Relying Party (RP): Consumes assertions/tokens to grant access.
- Federation Gateway / Broker: May translate protocols, aggregate identities, perform attribute enrichment.
- MetadataEndpoint: Provides cryptographic material, endpoints, and trust anchors (signed XML or JSON).
3.2 Federation Flow (Typical SAML‑Based)
- User accesses SP resource → SP checks for active session.
- SP sends
<AuthnRequest>to IdP via browser redirect. - IdP authenticates user (password, MFA) and creates an assertion.
- IdP redirects back to SP with the signed assertion.
- SP validates signature, extracts principal, establishes local session.
3.3 Federation Flow (Typical OIDC)
- User initiates login at SP → SP redirects to IdP
/authorize. - IdP authenticates user (MFA, step‑up) and returns
code(or token). - SP exchanges
codefor tokens (/token). - SP validates ID token (signature,
iss,aud,nonce). - SP establishes session and gains access to user attributes.
4. Comparing Protocol Mechanisms
| Aspect | SAML | OAuth 2.0 | OpenID Connect |
|---|---|---|---|
| Data Format | XML assertions | JSON tokens (opaque or JWT) | JWT (id_token) |
| Transport Binding | HTTP POST/Redirect/Artifact | HTTP/HTTPS only | HTTP/HTTPS |
| Transport Security | Signature required; optional encryption | TLS mandatory; token integrity via HMAC/JWS | Same as OAuth (TLS) plus claim validation |
| Common Use Case | Enterprise portal, SSO for web apps | API authorization, scoped access | User login, profile, SSO for SPAs & mobile |
| Token Handling | Assertion processed by application logic | Tokens passed to resource server | Tokens used for authentication and optional resource access |
| Logout Mechanism | Single Logout Protocol | OAuth Logout Extension (not standardized) | Front‑channel/Back‑channel logout (RFC 8417) |
5. Security Foundations
5.1 Assertion/Token Validation Checklist
- Signature Validation – Verify cryptographic signature using trusted key/certificate.
- Timestamp / Expiration – Respect
NotBefore,NotOnOrAfter,exp,iat. - Audience Check – Resource server must match its identifier in
audclaim. - Issuer / NameID Consistency – Must align with configured trust anchor.
- Replay Protection – Validate
InResponseTo,nonce, orhashof one‑time codes. - Signature Algorithm Whitelisting – Accept only
RS256/ES256/PS256; rejectnone,HS256unless explicitly allowed. - Key Identifier Handling – Resolve
kidto a valid JWKS entry; enforce key lifecycle (signing, encryption).
5.2 Common Threat Vectors & Mitigations
| Threat | Vector | Mitigation |
|---|---|---|
| Assertion Replay | Re‑use of old <Response> ID | Store short‑lived replay cache, validate InResponseTo. |
| Redirect URI Manipulation | Phishing via non‑registered URI | Precisely match registered redirect URIs; reject wildcards. |
| Signature Stripping | Omit signature element during parsing | Enforce mandatory <Signature> and schema validation. |
| Token Theft | Intercepting bearer tokens | Use short‑lived access tokens; bind tokens to client via PKCE or DPoP. |
| Algorithm Confusion | Switching from RS256 to HS256 | Enforce explicit algorithm list; reject none. |
| XML External Entity (XXE) | Malformed SAML XML | Disable external entity processing in XML parsers. |
5.3 Clock Synchronization
- Apply configurable skew tolerance (typically 60–300 seconds).
- Synchronize servers via NTP or PTP.
- Reject assertions/tokens outside allowed time windows.
6. Trust Establishment Workflow
6.1 Metadata Exchange
- SAML:
<EntityDescriptor>XML containingIdPSSODescriptorwith signing/encryption certificates, endpoints, and binding information. - OIDC:
/.well-known/openid-configurationprovides discovery URL, jwks_uri, authorization endpoint, etc. - Key Sharing: Exchange signing certificates (IdP → SP/RP) or public keys (JWKS).
6.2 Trust Validation Flow
- Metadata Retrieval – Pull signed metadata from trusted source.
- Signature Verification – Validate metadata signature using known federation root key.
- Endpoint Verification – Confirm endpoints match expected patterns.
- Certificate Chain Validation – Ensure chain ends at trusted root CA.
- Policy Comparison – Verify trust anchors against configured policy (e.g., allow only specific IdP IDs).
6.3 Federation Scenarios
- Direct IdP‑SP Trust: Simple one‑to‑one configuration.
- Indirect Trust via Authority: IdP trusts an intermediary Authority which trusts the final SP.
- Federated Identity Provider: SP trusts an IdP that aggregates multiple upstream IdPs (e.g., corporate directory).
7. Real‑World Application Scenarios
7.1 Enterprise Intranet SSO
- Use Case: Employees access internal web apps, HR systems, and legacy applications with a single corporate IdP.
- Typical Stack: IdP (e.g., Azure AD, ADFS), SP-side SAML Assertion Consumer Service, Backend Kerberos Integration for Windows apps.
7.2 Multi‑Tenant SaaS Platform
- Use Case: Each tenant’s users authenticate via their own IdP while sharing a common SaaS platform.
- Typical Stack: OIDC federation endpoints, Tenant‑scoped metadata, Dynamic client registration, JIT provisioning.
7.3 Business‑to‑Business (B2B) Integration
- Use Case: Partner companies exchange access to shared data pipelines.
- Typical Stack: SAML federation metadata exchange, Cross‑domain trust relationship, Attribute release policies (selective sharing).
8. Key Takeaways
- Identity federation decouples user authentication from application access, enabling a single identity to span multiple security domains.
- Trust is established through shared metadata, cryptographic verification, and explicit policy agreements.
- SAML, OAuth 2.0, and OpenID Connect address different layers of the authentication and authorization stack; understanding their scopes and message flows is critical for correct protocol selection.
- Secure validation (signature, audience, timestamp, replay protection) must be applied to every assertion or token before granting access.
- Protocol choice depends on the application landscape: SAML for legacy enterprise apps, OAuth/OIDC for modern APIs and SPAs, and hybrid approaches for mixed environments.