Standard · reviewed 2026-05-22

SAML 2.0 explained — when it’s still the right tool, when to migrate

SAML 2.0 is an XML-based authentication + assertion protocol for enterprise SSO. Older than OIDC, but still dominant in B2B and on-prem.

Read the spec

SAML 2.0 SP-initiated federation flow with browser as the intermediary between identity provider and service provider

TL;DR

SAML 2.0 (OASIS, 2005) is the SSO protocol that established the modern federation pattern: an Identity Provider issues a signed XML assertion to a Service Provider after authenticating a user. It's verbose, XML-heavy, and not what you'd design today — but it's ubiquitous in B2B SSO + government + on-prem. Replacing it with OIDC is the right long-term direction; doing so prematurely on B2B surfaces is the wrong short-term direction.

Published by

OASIS Security Services Technical Committee

Spec

SAML 2.0 Core (OASIS Standard, March 2005)

Who uses it

Every enterprise IdP. Every B2B SaaS that supports SSO with enterprise customers. US federal government (eAuthentication, ICAM). Education sector (Shibboleth). Health-sector tooling (Epic, Cerner). On-prem identity products.

Reviewed

2026-05-22

When to use

You're integrating with a B2B customer who insists on SAML (very common in regulated enterprises). You're publishing to .gov or .edu. You're on a stack where the IdP only speaks SAML.

When not to use

New consumer-facing apps (use OIDC). Mobile / native clients (use OIDC + Authorization Code + PKCE). API authentication for service-to-service (use OAuth 2.1 Client Credentials). Anywhere you have a choice and the counterparty supports OIDC.

The flow (Web Browser SSO Profile)

The most-used SAML 2.0 profile. Two variants: IdP-Initiated and SP-Initiated. SP-Initiated is the security default — the SP knows it asked.

1. User visits SP (e.g. https://app.example.com)
2. SP redirects user to IdP with an AuthnRequest:
     https://idp.example.com/sso?SAMLRequest=<base64-deflated>&RelayState=<csrf>
3. User authenticates at IdP (MFA, password, certificate, ...)
4. IdP POSTs a signed SAML Response back to the SP's ACS URL:
     POST https://app.example.com/saml/acs
     SAMLResponse=<base64-encoded>&RelayState=<csrf>
5. SP validates:
     - Signature on the Response (or on the inner Assertion)
     - NotBefore / NotOnOrAfter (clock skew tolerated)
     - Audience restriction matches the SP's entity ID
     - Issuer matches the trusted IdP
6. SP creates a local session and redirects to the requested resource

What's in a SAML Response

A SAML Response is an XML document with three things that matter:

Assertion — the actual claim about the user. Contains the `<Subject>` (typically a NameID = email or directory ID) and an `<AttributeStatement>` with group memberships, roles, and other attributes the IdP chose to release.
Conditions — `<NotBefore>` and `<NotOnOrAfter>` time bounds + an `<AudienceRestriction>` naming the SP. Replay-protection.
Signature — XML-DSig over the Response or the inner Assertion. The SP must validate this against the IdP's certificate from metadata.

Common failure modes

The recurring debugging surface for SAML integrations:

Clock skew. NotBefore / NotOnOrAfter fail when the SP and IdP clocks drift. Tolerance is typically 5 minutes; some implementations are stricter.
Attribute name mismatch. IdP releases `mail`; SP expects `email`. Or IdP releases `groups` as a single comma-separated string; SP expects multi-value.
Signature verification. Metadata cert rotation breaks signature validation. Most IdPs publish a metadata URL the SP refreshes daily.
Encoding. SAML responses are sometimes base64-encoded directly, sometimes base64 + deflate (HTTP-Redirect binding). Decoders should try both.
Wrong binding. HTTP-POST vs HTTP-Redirect. POST is the default for the Response. Redirect is for the AuthnRequest.

SAML vs OIDC — when each wins

OIDC is the modern default. SAML still wins in specific contexts:

B2B SSO with regulated buyers. Banks, hospitals, govt buyers often require SAML. Easier to support than to argue.
Education + research federations. Shibboleth + InCommon ecosystems are SAML-native.
Government identity. US federal eAuthentication, UK Government Verify, etc. are SAML-anchored.
Existing infrastructure. If your IdP and SP already speak SAML and the integration works, migrating to OIDC has cost without obvious benefit.

FAQ

Questions we get on this standard.

What is SAML?
SAML (Security Assertion Markup Language) is an XML-based open standard for single sign-on and identity federation. It lets an identity provider (IdP) authenticate a user once and then assert "this is who the user is, and here are their attributes" to a service provider (SP) via a signed XML assertion — so the user logs into many applications without re-entering credentials. SAML 2.0 (2005) is the dominant version and the long-standing default for enterprise SSO.
Is SAML 2.0 still maintained?
The core spec hasn't been updated since 2005, but the surrounding ecosystem (metadata profiles, federations, IdP product implementations) actively evolves. SAML 2.0 is "stable" — no breaking changes are coming.
Should we replace our SAML integration with OIDC?
On consumer-facing surfaces, yes — OIDC is simpler and modern. On B2B integrations where the customer chose SAML, no — replacing it costs them a configuration change for no benefit they'll see.
How does SAML handle signing-cert rotation?
Via the IdP's metadata document, which lists current + next signing certs. The SP polls metadata regularly (daily is typical) and accepts assertions signed by either cert during a rotation window.

Use the tool

SAML Response Decoder

Understanding the spec is the easy part.

We implement SAML 2.0 integrations across regulated enterprises — workforce SSO, B2B SaaS federation, customer identity. Same-day reply.

Talk to a practice leadMore explainers

The flow (Web Browser SSO Profile)

The most-used SAML 2.0 profile. Two variants: IdP-Initiated and SP-Initiated. SP-Initiated is the security default — the SP knows it asked.

1. User visits SP (e.g. https://app.example.com) 2. SP redirects user to IdP with an AuthnRequest: https://idp.example.com/sso?SAMLRequest=<base64-deflated>&RelayState=<csrf> 3. User authenticates at IdP (MFA, password, certificate, ...) 4. IdP POSTs a signed SAML Response back to the SP's ACS URL: POST https://app.example.com/saml/acs SAMLResponse=<base64-encoded>&RelayState=<csrf> 5. SP validates: - Signature on the Response (or on the inner Assertion) - NotBefore / NotOnOrAfter (clock skew tolerated) - Audience restriction matches the SP's entity ID - Issuer matches the trusted IdP 6. SP creates a local session and redirects to the requested resource

What's in a SAML Response

A SAML Response is an XML document with three things that matter:

Assertion — the actual claim about the user. Contains the `<Subject>` (typically a NameID = email or directory ID) and an `<AttributeStatement>` with group memberships, roles, and other attributes the IdP chose to release.

Conditions — `<NotBefore>` and `<NotOnOrAfter>` time bounds + an `<AudienceRestriction>` naming the SP. Replay-protection.

Signature — XML-DSig over the Response or the inner Assertion. The SP must validate this against the IdP's certificate from metadata.

Common failure modes

The recurring debugging surface for SAML integrations:

Clock skew. NotBefore / NotOnOrAfter fail when the SP and IdP clocks drift. Tolerance is typically 5 minutes; some implementations are stricter.

Attribute name mismatch. IdP releases `mail`; SP expects `email`. Or IdP releases `groups` as a single comma-separated string; SP expects multi-value.

Signature verification. Metadata cert rotation breaks signature validation. Most IdPs publish a metadata URL the SP refreshes daily.

Encoding. SAML responses are sometimes base64-encoded directly, sometimes base64 + deflate (HTTP-Redirect binding). Decoders should try both.

Wrong binding. HTTP-POST vs HTTP-Redirect. POST is the default for the Response. Redirect is for the AuthnRequest.

SAML vs OIDC — when each wins

OIDC is the modern default. SAML still wins in specific contexts:

B2B SSO with regulated buyers. Banks, hospitals, govt buyers often require SAML. Easier to support than to argue.

Education + research federations. Shibboleth + InCommon ecosystems are SAML-native.

Government identity. US federal eAuthentication, UK Government Verify, etc. are SAML-anchored.

Existing infrastructure. If your IdP and SP already speak SAML and the integration works, migrating to OIDC has cost without obvious benefit.

Questions we get on this standard.

What is SAML?

SAML (Security Assertion Markup Language) is an XML-based open standard for single sign-on and identity federation. It lets an identity provider (IdP) authenticate a user once and then assert "this is who the user is, and here are their attributes" to a service provider (SP) via a signed XML assertion — so the user logs into many applications without re-entering credentials. SAML 2.0 (2005) is the dominant version and the long-standing default for enterprise SSO.

Is SAML 2.0 still maintained?

The core spec hasn't been updated since 2005, but the surrounding ecosystem (metadata profiles, federations, IdP product implementations) actively evolves. SAML 2.0 is "stable" — no breaking changes are coming.

Should we replace our SAML integration with OIDC?

On consumer-facing surfaces, yes — OIDC is simpler and modern. On B2B integrations where the customer chose SAML, no — replacing it costs them a configuration change for no benefit they'll see.

How does SAML handle signing-cert rotation?

Via the IdP's metadata document, which lists current + next signing certs. The SP polls metadata regularly (daily is typical) and accepts assertions signed by either cert during a rotation window.