SSO and Identity Federation: SAML 2.0 and OIDC

Single Sign-On (SSO) and identity federation are the foundation of modern access control: a user authenticates once at an Identity Provider (IdP) and accesses dozens of applications without re-entering credentials. When well implemented, SSO reduces weak reused passwords, centralizes the MFA enforcement point and simplifies auditing. When poorly configured, it concentrates risk in a single critical node. This guide covers the two dominant protocols — SAML 2.0 and OIDC — their flows, differences, market IdPs, provisioning via SCIM, known attacks and the relationship with Zero Trust.

What identity federation is

Identity federation is the set of agreements, standards and technologies that allow systems from distinct domains to share authentication information in a secure and verifiable way. Instead of each application maintaining its own user database and login logic, it trusts an assertion issued by a trusted third party — the Identity Provider. The Service Provider (SP) cryptographically validates the assertion and grants access without ever needing to know the user's password.

Federation solves three practical problems: it eliminates credential proliferation (a user across 40 SaaS apps has 40 distinct passwords); it enables centralized lifecycle management (offboarding an employee at the IdP revokes access to all federated systems); and it allows security policies — MFA, device posture, geolocation — to be enforced at a single point before any access is granted.

SAML 2.0: XML assertions for the enterprise

Security Assertion Markup Language 2.0, standardized by the OASIS consortium in 2005 (SAML Core 2.0 specification), defines a protocol for exchanging XML assertions between Identity Provider and Service Provider. A SAML assertion is a digitally signed XML document that declares who the user is (Authentication Statement), which attributes they hold (Attribute Statement) and what they are authorized to do (Authorization Decision Statement).

Roles in SAML

• Identity Provider (IdP): authenticates the user and issues the assertion signed with its private key. Examples: Microsoft Entra ID (formerly Azure AD), Okta, Keycloak, Google Workspace, PingFederate.
• Service Provider (SP): receives the assertion, validates the signature with the IdP's public certificate and grants access. Examples: Salesforce, AWS Console, Jira, any application configured for SAML.
• Principal: the user who initiates the authentication flow.

SP-Initiated flow (most common)

1. The user accesses the protected URL on the Service Provider.
2. The SP detects that the user is not authenticated and generates an XML AuthnRequest, Base64-encoded and sent via HTTP redirect to the IdP.
3. The IdP authenticates the user (password + MFA) and issues an XML Response containing the signed assertion.
4. The IdP sends the Response via POST to the SP's Assertion Consumer Service URL (ACS URL).
5. The SP validates the signature, checks the temporal validity (NotBefore/NotOnOrAfter), extracts the attributes and creates the user's session.

In the IdP-Initiated flow, the user starts from the IdP portal and the SP receives the assertion without having generated an AuthnRequest — which increases the risk of replay attacks and should be avoided or heavily monitored.

OIDC and OAuth 2.0: JWT tokens for the modern world

OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0, published by the OpenID Foundation in 2014. Where OAuth 2.0 defines an authorization framework (access delegation), OIDC adds authentication through the ID Token — a signed JWT (JSON Web Token) that contains claims about the authenticated user.

Tokens in OIDC

• ID Token: JWT signed by the IdP that proves who the user is. Contains standard claims: sub (unique identifier), email, name, iss (issuer), aud (audience), exp (expiration).
• Access Token: opaque token or JWT used to access protected resources (APIs). Short-lived.
• Refresh Token: long-lived token used to obtain new Access Tokens without re-authenticating the user.

Authorization Code Flow with PKCE

The recommended flow for web and mobile applications is the Authorization Code Flow with Proof Key for Code Exchange (PKCE, RFC 7636). The client generates a random code_verifier and sends its hash (code_challenge) in the authorization request. The authorization server returns a short-lived code; the client exchanges that code for the token by presenting the original code_verifier. This prevents code interception attacks even on channels that are not fully secure.

SAML 2.0 vs OIDC comparison

Dimension	SAML 2.0	OIDC / OAuth 2.0
Token format	XML (signed assertion)	JWT (JSON, compact)
Transport	HTTP Redirect / POST (browser)	HTTP (browser, API, mobile)
Target applications	Enterprise web, legacy, B2B SaaS	SPAs, mobile, microservices, APIs
Implementation complexity	High (XML, certificates, metadata)	Moderate (JSON, mature libraries)
Authorization support	Limited (Authorization Decision)	Native via OAuth 2.0 scopes
Single Logout (SLO)	Supported (SAML SLO profile)	Partial (Front-Channel Logout, OIDC Back-Channel)
Ecosystem	Salesforce, AWS, SAP, legacy	Google, GitHub, AWS Cognito, Stripe
Reference standard	OASIS SAML 2.0 (2005)	OpenID Foundation OIDC Core 1.0 (2014)

Market Identity Providers

Microsoft Entra ID (Azure AD): dominant in Microsoft 365 environments. Supports SAML 2.0, OIDC, WS-Federation and SCIM. Offers Conditional Access (policies based on risk, location, device) and native integration with Windows Hello for Business.

Okta Workforce Identity: stack-agnostic IdP with a catalog of thousands of pre-built integrations (OIN). Strong in just-in-time provisioning, Adaptive MFA and Universal Directory. A reference for multi-cloud organizations.

Keycloak: open-source IdP maintained by Red Hat, ideal for on-premises or private-cloud environments. Supports SAML 2.0, OIDC, LDAP/AD as a federation source and allows deep customization via themes and Java extensions.

Google Workspace: integrated IdP for Google-first organizations. Supports SAML 2.0 with third-party apps and native OIDC for Google applications. Context-Aware Access enables device-based policies.

SCIM: automatic lifecycle provisioning

System for Cross-domain Identity Management (SCIM 2.0, RFC 7642–7644) is a REST + JSON protocol for synchronizing identity directories. When HR onboards or offboards an employee in the source system (Workday, SuccessFactors, the AD itself), the IdP propagates that change via SCIM to all connected Service Providers: it creates the account, updates groups, suspends or removes — in minutes, not days.

SCIM eliminates two of the biggest security failures in enterprise IAM: orphaned accounts of former employees that remain active weeks after offboarding, and manual provisioning with excessive permissions due to the lack of a correct template. Implementation requires the SP to support the SCIM endpoint (most modern SaaS do) and the IdP to have the connector configured with the SP's authentication token.

JIT Provisioning

Just-in-Time (JIT) provisioning creates the user's account on the Service Provider at the moment of the first successful SSO login, using the attributes from the SAML assertion or the OIDC ID Token. It is an alternative to SCIM for SPs that do not support the provisioning protocol or for organizations with an external user base (partners, B2B customers). The downside is that JIT does not remove accounts automatically: offboarding at the IdP prevents future logins, but the account on the SP continues to exist until it is removed manually or by cron.

Known risks and attacks

Golden SAML

If an attacker compromises the IdP's private key — obtained via a memory dump of AD FS, access to the Okta server or an improper export of Keycloak — they can forge valid SAML assertions for any user, including administrators, without needing a password or MFA. The attack was publicly documented in APT campaigns (Solorigate/SolarWinds). Countermeasures: store keys in a dedicated HSM or Azure Key Vault/AWS KMS; monitor certificate exports; alert on assertions with administrator attributes issued outside business hours.

OIDC Misconfiguration: Redirect URI Abuse

Registering Redirect URIs with wildcards (https://app.com/*) or accepting arbitrary URIs allows an attacker to redirect the Authorization Code to an endpoint under their control and exchange it for tokens. Rule: Redirect URIs must be exact and periodically reviewed. Removing URIs from discontinued applications is frequently overlooked.

Token Replay and missing audience validation

JWTs without strict validation of the aud (audience) claim can be accepted by SPs that were not the original recipient. SAML assertions without NotOnOrAfter verification allow replay of captured tokens. Every SP implementation must validate: signature, issuer (iss), audience (aud), temporal validity and — for SAML — the InResponseTo matching the original AuthnRequest.

No MFA at the IdP

SSO without MFA concentrates risk in a single password. Compromising one IdP credential is equivalent to compromising all federated systems. MFA must be mandatory at the IdP for all users, with no exceptions. Adaptive MFA policies (requiring a second factor only in high-risk contexts) are a complement, not a substitute.

Implementation best practices

• Enable assertion signing and, where possible, encryption of the SAML assertion (EncryptedAssertion) for sensitive data.
• Configure the IdP session lifetime to be compatible with the security policy: convenient long sessions are high-risk sessions on shared devices.
• Implement Single Logout (SLO) so that logging out of one SP propagates session termination to the IdP and the other SPs.
• Keep an up-to-date inventory of all Service Providers registered at the IdP; remove inactive integrations.
• Monitor the IdP's authentication logs in the SIEM: patterns of simultaneous logins from distinct locations, assertions issued outside expected hours, repeated signature validation failures.
• Rotate SAML certificates before expiration; test the rotation in staging to avoid production outages.
• Do not expose the IdP's XML metadata publicly without need; it contains endpoint and certificate information useful for reconnaissance.

SSO and Zero Trust

The Zero Trust model (NIST SP 800-207) assumes that no network is trusted and that every access request must be explicitly verified based on identity, device posture and context. SSO and federation are pillars of this model: without strong federated identity, there is no way to enforce granular per-resource policies. The Zero Trust flow extends SSO with additional checks: the IdP evaluates whether the device is managed (MDM), whether the security endpoint is active, whether the session comes from an expected IP or location — and only then issues the token with the appropriate scopes.

Solutions such as Cloudflare Access, Zscaler Private Access and Microsoft Entra Private Access act as identity proxies in front of internal applications, replacing traditional VPNs: the user authenticates via OIDC at the IdP, the proxy validates the token and the context policies, and only then forwards the connection to the internal resource. Legacy applications without SAML or OIDC support are protected without code changes.

Normative and technical references

• OASIS SAML 2.0 Core Specification (2005) — docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
• OpenID Connect Core 1.0 — openid.net/specs/openid-connect-core-1_0.html
• OAuth 2.0 Authorization Framework — RFC 6749 (IETF)
• PKCE — RFC 7636 (IETF)
• SCIM 2.0 — RFC 7642, 7643, 7644 (IETF)
• NIST Special Publication 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management
• NIST SP 800-207 — Zero Trust Architecture

Frequently asked questions

What is the difference between SAML 2.0 and OIDC?

SAML 2.0 exchanges XML assertions between Identity Provider and Service Provider, and is dominant in legacy corporate applications and web SSO. OIDC uses JWT tokens over OAuth 2.0 and is the natural choice for modern applications, APIs, mobile and SPAs. The decision depends on the application stack: SAML for traditional enterprise systems; OIDC for microservices and cloud-native.

Does SSO reduce or increase the attack surface?

SSO concentrates the authentication vector in a single point, which simplifies monitoring and enables uniform MFA and session policies. The risk increases only if the Identity Provider is compromised or misconfigured — which is why it requires hardened IdP protection, mandatory MFA, certificate rotation and monitoring of suspicious assertions.

What is the golden SAML attack and how do I prevent it?

Golden SAML occurs when an attacker obtains the Identity Provider's private key and forges valid SAML assertions for any user without needing credentials. Prevention requires: storing the IdP's private keys in an HSM or secrets vault, monitoring logins with unusual attributes, enabling signature verification at the SP and periodically reviewing active certificates.

What is JIT provisioning and when should I use it?

Just-in-Time provisioning automatically creates the user's account on the Service Provider at the moment of the first successful SSO login. It is useful when the user base changes frequently (contractors, partners). For more granular lifecycle control — immediate deactivation, dynamic groups — prefer SCIM, which updates accounts in real time via REST API.

Can I use SSO with applications that support neither SAML nor OIDC?

Yes. Solutions such as Cloudflare Access or authentication proxies act as an identity header in front of the legacy application, injecting headers such as X-User or X-Email after federated authentication. The application does not need to implement any protocol. This approach is compatible with the Zero Trust model: the proxy verifies identity and device posture before routing the request.

Does SCIM replace SAML or OIDC?

No. SAML and OIDC are authentication protocols; SCIM (RFC 7642–7644) is a provisioning protocol. They complement each other: SAML or OIDC authenticates the user, SCIM synchronizes the directory — it creates, updates and removes accounts and groups at the destination automatically when HR changes the record at the IdP.

How Decripte implements SSO and federation

Decripte designs and implements federated identity architectures for organizations from 1 to more than 100,000 employees. The scope includes Identity Provider selection and configuration (Entra ID, Okta, Keycloak), SAML 2.0 and OIDC integration with the company's application portfolio, automated provisioning via SCIM, mandatory MFA policies, monitoring of authentication events in the SIEM and IT team training. The result is an identity posture that is auditable, scalable and aligned with NIST 800-63 and the Zero Trust model.

Companies still operating with local passwords in each system, without centralized visibility of who accesses what, are exposed to risks that a well-configured SSO eliminates directly and measurably. Start with the free Threat Management plan to get a diagnostic of your current posture, or explore Decripte's plans for a complete IAM implementation with SSO, MFA and Zero Trust.