🔗 SSO Fundamentals
Single Sign-On (SSO) allows a user to authenticate once to a central Identity Provider (IdP) and then access multiple Service Providers (SPs) — applications and services — without re-authenticating. The IdP vouches for the user's identity to each SP through a federation protocol, establishing a trust relationship between them.
The key participants in SSO: the Identity Provider (IdP) authenticates the user and issues assertions or tokens; the Service Provider (SP) accepts the IdP's assertion and grants access; and the User Agent (browser or native client) facilitates the redirects between them. Trust is established via metadata exchange — the SP trusts the IdP's signing certificate; the IdP knows the SP's redirect URIs.
| Attribute | Without SSO | With SSO |
|---|---|---|
| Passwords per user | One per application (often 20–50+) | One master IdP credential + MFA |
| Password quality | Users reuse or weaken passwords | One strong password with enforced MFA |
| MFA coverage | Varies per app; often inconsistent | Enforced centrally for all apps |
| Offboarding speed | Must disable accounts in every app | Disable IdP account; access to all apps revoked |
| Access visibility | Siloed per application | Centralized audit log at IdP |
| User experience | Frequent login prompts | Seamless access after single login |
| Compliance | Separate evidence per application | Centralized access reports and audit trails |
SSO as a Single Point of Failure
SSO concentrates authentication — if the IdP is unavailable, users cannot access any federated application. Mitigations: (1) deploy IdP with high availability (clustered, multi-region); (2) configure SP-side session caching so brief IdP outages don't affect active sessions; (3) maintain break-glass local accounts for critical systems; (4) test IdP failover quarterly. The IdP also becomes the highest-value target for attackers — protect it with the strongest available MFA, PAM controls on admin accounts, and dedicated monitoring.
📜 SAML 2.0
Security Assertion Markup Language 2.0 (SAML 2.0, OASIS 2005) is the dominant federation protocol in enterprise SSO. It uses XML-based assertions signed with XML Digital Signatures to convey authentication and attribute information from IdP to SP.
SP-Initiated Flow (Most Common)
User visits the SP, is redirected to the IdP's SSO endpoint with an AuthnRequest, authenticates at the IdP, and is redirected back to the SP's Assertion Consumer Service (ACS) URL with a signed SAML Response containing assertions.
- 1. User requests resource at SP
- 2. SP generates AuthnRequest, redirects to IdP
- 3. User authenticates at IdP (password + MFA)
- 4. IdP posts signed SAML Response to SP's ACS URL
- 5. SP validates signature, extracts NameID, grants access
IdP-Initiated Flow
User starts at the IdP portal (e.g., Okta dashboard), clicks an application tile, and the IdP generates and posts an unsolicited SAML Response to the SP. No AuthnRequest from the SP — the SP must accept unsolicited responses if this flow is enabled.
- 1. User logs in to IdP application portal
- 2. User clicks application tile
- 3. IdP generates signed SAML Response
- 4. Browser POSTs to SP's ACS URL
- 5. SP validates and creates session
SAML Assertion Types
A SAML Response contains one or more assertions, each with a specific purpose. All assertions are digitally signed by the IdP to prevent tampering.
- Authentication assertion: confirms the user authenticated, when, and how (AuthnContext)
- Attribute assertion: carries user attributes (email, groups, department) for authorization
- Authorization decision assertion: rare; states whether access to a resource is permitted
SAML Security Vulnerabilities
SAML's XML foundation introduces attack vectors that pure token-based protocols avoid. These vulnerabilities have been found in major enterprise IdPs and SPs.
- XML Signature Wrapping (XSW): attacker wraps malicious assertion alongside valid signed assertion; parser reads unsigned one
- Open Redirects: RelayState parameter not validated; used for phishing redirect
- XML External Entity (XXE): if XML parser has XXE enabled, can read files from SP server
- Replay attacks: lack of InResponseTo or timestamp validation
🔄 OpenID Connect & OAuth 2.0
OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0, standardized by the OpenID Foundation in 2014. Where OAuth 2.0 is an authorization delegation framework (granting apps access to resources), OIDC adds authentication — telling the client who the user is via a signed JWT ID token.
OAuth 2.0 Roles
OAuth 2.0 defines four roles in the authorization flow. Understanding them is essential to correctly implementing and securing OAuth-based integrations.
- Resource Owner: the user who owns the data
- Client: the application requesting access
- Authorization Server: issues access tokens (your IdP)
- Resource Server: the API being accessed (validates tokens)
Authorization Code + PKCE Flow
The recommended OIDC flow for web and mobile applications. PKCE (Proof Key for Code Exchange, RFC 7636) prevents authorization code interception attacks in public clients (SPAs, mobile apps) that cannot store a client secret.
- 1. Client generates code_verifier and code_challenge
- 2. Authorization request includes code_challenge
- 3. User authenticates; IdP issues authorization code
- 4. Client exchanges code + code_verifier for tokens
- 5. IdP verifies challenge matches verifier before issuing tokens
ID Token vs Access Token
OIDC introduces two distinct tokens with different purposes. Confusing them leads to security vulnerabilities.
- ID Token (JWT): for the client to verify who authenticated; contains user claims (sub, email, name); must NOT be sent to APIs
- Access Token: for the client to call protected APIs on the user's behalf; Resource Server validates it; may be opaque or JWT
- Refresh Token: long-lived; used to obtain new access tokens without re-auth
OIDC vs SAML — When to Use Each
Both protocols accomplish federation, but they have different strengths, and many enterprise environments deploy both.
- OIDC: modern web/mobile apps, APIs, developer-friendly, JSON/REST
- SAML: legacy enterprise apps, on-prem, XML ecosystems
- Most major SaaS apps support both; prefer OIDC for new integrations
- Microsoft 365 / Azure: OIDC for most modern scenarios
- Legacy ERP / enterprise apps (ServiceNow, Workday): SAML
OAuth 2.0 Scopes and Token Validation
OAuth 2.0 scopes define what access the client is requesting (e.g., openid profile email). Clients must request minimum necessary scopes — over-permissioned OAuth apps are a common attack vector. Resource servers must validate access tokens on every request: check signature, expiry (exp), audience (aud), issuer (iss), and required scopes. Never accept tokens from unexpected issuers or with mismatched audiences.
🏢 Enterprise SSO Platforms
Okta Workforce Identity
The leading independent SSO and identity platform. 7,000+ pre-built app integrations in the Okta Integration Network. Strong lifecycle management (Okta Lifecycle Management), adaptive MFA, and Universal Directory for consolidating identity sources.
- SAML, OIDC, WS-Fed support
- Adaptive MFA with behavior analytics
- API Access Management (OAuth authorization server)
- Okta Customer Identity (CIAM) for consumer-facing apps
Microsoft Entra ID
Formerly Azure Active Directory. The dominant IdP for organizations in the Microsoft 365 ecosystem. Conditional Access policies are deeply integrated with Intune device compliance, Defender for Endpoint signals, and the full Microsoft security stack.
- Seamless SSO for hybrid AD environments
- Conditional Access + Continuous Access Evaluation
- B2B (guest access) and B2C (customer identity)
- Entra ID Governance for IGA workflows
Ping Identity
Focused on hybrid and legacy enterprise integration. Strong in scenarios where organizations have on-prem legacy applications that cannot move to cloud IdPs. PingFederate handles complex federation topologies including multi-domain SAML brokering.
- PingFederate: on-prem or hybrid federation gateway
- PingOne: cloud-hosted IdP
- Handles mainframe, legacy app, custom protocol integration
- Strong in financial services and large enterprises
Self-Hosted Options
For organizations requiring on-premise control, open-source SSO platforms offer full feature sets without vendor lock-in. These require more operational overhead but eliminate per-user pricing and SaaS dependency.
- Keycloak (Red Hat): full-featured, Kubernetes-native, Java
- Authentik: modern, Docker-native, excellent UI/UX
- Authelia: lightweight, reverse-proxy focused, 2FA gateway
- Casdoor: Go-based, multi-tenant
| Platform | Pricing Model | SAML | OIDC | SCIM | On-prem Option |
|---|---|---|---|---|---|
| Okta | Per-user/month | Yes | Yes | Yes | No (cloud only) |
| Azure Entra ID | Per-user/month (P1/P2) | Yes | Yes | Yes | Hybrid (AD Connect) |
| Ping Identity | Per-user/month (enterprise) | Yes | Yes | Yes | Yes (PingFederate) |
| JumpCloud | Per-user/month (SMB) | Yes | Yes | Yes | No (cloud only) |
| Keycloak | Free (open source) | Yes | Yes | Yes | Yes |
| Authentik | Free / Enterprise | Yes | Yes | Yes | Yes |
🔒 SSO Security Best Practices
Protect Your IdP Above All Else
The IdP is the master key to your organization. Its compromise grants access to every federated application. Apply your highest security standards here.
- Enforce phishing-resistant MFA (FIDO2) for all IdP admin accounts
- Apply PAM controls on IdP admin access
- Monitor for admin account changes and federation config modifications
- Alert on new trusted identity providers or SAML metadata changes
- Separate IdP admin accounts from user accounts
SCIM Provisioning
SCIM (System for Cross-domain Identity Management, RFC 7643/7644) automates user and group provisioning/deprovisioning from your IdP to connected SaaS applications. Essential for timely offboarding.
- Enable SCIM sync between IdP and all major SaaS apps
- Deprovisioning triggered automatically on IdP account disable
- SCIM tokens should be rotated and stored in a vault
- Monitor SCIM sync errors — failed deprovisioning = orphaned accounts
- Test deprovisioning flow in staging before production
Session Management
SSO sessions must be carefully managed — a long IdP session means an attacker who steals the session cookie maintains persistent access across all federated apps.
- Set appropriate IdP session lifetime (8–12 hours typical)
- Require re-authentication for sensitive applications (step-up)
- Enable Continuous Access Evaluation (CAE) where supported
- Single logout (SLO) propagation: IdP logout should invalidate SP sessions
- Token binding to prevent session token theft and replay
Federation Metadata Validation
SAML federation relies on metadata — the XML document describing each party's endpoints and certificates. Metadata poisoning or outdated metadata can lead to security gaps.
- Validate SAML metadata signatures before import
- Monitor certificate expiry dates proactively
- Automate metadata refresh where the IdP supports dynamic metadata
- Restrict ACS URLs to known, expected endpoints
- Review and audit registered SP integrations quarterly
JIT Provisioning & Attribute Mapping
Just-in-Time (JIT) provisioning automatically creates user accounts in an SP when a user first authenticates via SSO, without requiring pre-provisioned accounts. The SP creates the account based on SAML attributes or OIDC claims. Combined with attribute-based authorization, this enables fine-grained access control: the IdP sends group membership or role attributes in the assertion; the SP uses these to determine what the user can do. Example: the IdP asserts groups: ["finance-read", "hr-admin"] and the SP maps these to application roles.
Your SSO IdP Is the Master Key to Your Organization
In a mature SSO deployment, compromising the IdP means compromising every application that trusts it — email, HR systems, financial systems, source code, customer data. Protect it accordingly: FIDO2-only MFA for all admin access, privileged session management for IdP admin consoles, dedicated monitoring and SIEM integration, quarterly access reviews for IdP admin roles, and immutable audit logging for all configuration changes. Do not run your IdP on the same infrastructure as other services — treat it as critical infrastructure with its own security boundary.