SAML 2.0 (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between an identity provider and a service provider. It has powered enterprise web single sign-on since 2005 and remains the protocol most corporate identity providers speak.

What is the difference between SAML and OIDC?

SAML 2.0 is an older XML-based standard built for browser-based enterprise SSO, while OpenID Connect is a modern JSON and JWT-based protocol built for web, mobile, and APIs. Both do single sign-on; new applications usually choose OIDC, but SAML persists because enterprise identity providers and legacy integrations still require it.

What is the difference between SP-initiated and IdP-initiated SAML?

In an SP-initiated flow, the user starts at the application (service provider), which redirects them to the identity provider to authenticate. In an IdP-initiated flow, the user starts at the identity provider's portal and launches the application from there. SP-initiated is generally preferred because IdP-initiated flows are more exposed to certain replay and injection risks.

Is SAML 2.0 still used in 2026?

Yes. SAML 2.0 is a stable OASIS standard and remains deeply entrenched for workforce SSO across enterprises. Most identity platforms support both SAML and OIDC, so vendors selling to enterprises are still expected to support SAML.

SAML 2.0 Explained: How It Works & When to Use It (2026)

What it is

SAML 2.0 (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization assertions between an identity provider and a service provider. It has powered enterprise web single sign-on since 2005, and if you sell to enterprises you will be asked to support it because that is what their identity providers speak.

How it works

The identity provider (IdP) authenticates the user and issues a signed XML assertion to the service provider (SP), which trusts it and grants access.

Assertion: a signed XML document stating who the user is and when they authenticated.
SP-initiated vs IdP-initiated: the flow can start at the application or at the identity provider's portal.
Metadata: IdP and SP exchange metadata describing endpoints and signing keys.

The core documents are the OASIS Assertions and Protocols, Bindings and Profiles specifications, plus the approved errata. The flow most deployments use is the Web Browser SSO profile:

The user opens https://app.example.com. The SP builds an <AuthnRequest> with a unique ID, its entity ID as <Issuer>, and its Assertion Consumer Service (ACS) URL, then redirects the browser to the IdP using the HTTP-Redirect binding (deflated, base64, URL-encoded, optionally signed).
The IdP authenticates the user, applying its own MFA and conditional access policy.
The IdP returns an auto-submitting HTML form that POSTs a <Response> to the ACS URL (HTTP-POST binding). Inside is an <Assertion> with the <Subject> (a <NameID> such as an email or persistent identifier, the SSO identifier the SP keys the account on), <Conditions> with NotBefore, NotOnOrAfter and an <AudienceRestriction> naming the SP, an <AuthnStatement>, and usually an <AttributeStatement> with groups or roles.
The SP validates the response and creates its own session.

What the SP must validate

Most SAML vulnerabilities are validation bugs, not protocol flaws. A correct SP checks, in order:

The signature covers the assertion you will read. Verify the XML signature with the IdP's certificate from metadata (never a key embedded in the message), and confirm the signed element is the same element your code then extracts attributes from. Signature wrapping attacks exploit exactly that gap.
Issuer matches the expected IdP entity ID.
AudienceRestriction contains your SP entity ID.
Recipient and Destination match your ACS URL.
InResponseTo matches an AuthnRequest ID you issued and have not seen used (blocks replay and unsolicited responses in SP-initiated flows).
Time window: NotBefore and NotOnOrAfter, with small clock skew allowance.
One assertion only, and reject responses with unexpected extra assertions.

Where SAML breaks in practice

The SWI identity CVE catalog shows the pattern repeatedly:

Signature wrapping through parser differentials. In CVE-2025-25291 and CVE-2025-25292, two XML parsers inside ruby-saml disagreed about the same document, so an attacker with one valid signed assertion could wrap a forged one and log in as any user. Both are descendants of CVE-2024-45409.
Optional encryption paths. CVE-2024-4985 let a forged response through GitHub Enterprise Server when encrypted assertions were enabled, allowing provisioning of a site administrator.
Appliance SSO bypass. CVE-2025-59718, a crafted SAML message bypassing FortiCloud SSO on FortiOS and related products, was added to CISA KEV in December 2025. The breach database record covers its exploitation.
Forging at the source. If an attacker steals the IdP's signing key, every SP will accept their assertions. That is the federation trust abuse and SAML forgery technique, often called Golden SAML.

These are why the advice below is "use a maintained library and patch it", not "write careful XML code".

Status

SAML 2.0 is a stable OASIS standard and remains deeply entrenched in enterprise IT. For new consumer, mobile, and API-centric apps, OpenID Connect is the better choice, but most enterprises still require SAML for workforce SSO, so platforms support both.

When to use it

When integrating with enterprise customers or established corporate identity providers. For greenfield modern apps, prefer OIDC. SWI's Phishing-Resistant MFA Support Matrix found SAML offered by 83 of 95 business SaaS apps and OpenID Connect by 30, so an OIDC-first identity provider still needs SAML for most of a SaaS estate.

SAML and AI agents

SAML has no token an agent can carry to an API, which is why agent standards build on OAuth. It is not a dead end, though. The ID-JAG draft (Cross App Access) defines SAML interoperability: a client that signed the user in with SAML exchanges the assertion at the IdP for a refresh token, using token exchange with the urn:ietf:params:oauth:token-type:saml2 token type, and then uses that refresh token to request ID-JAGs for other apps. The IdP must map the assertion's audience to an OAuth client ID first. The MCP Enterprise-Managed Authorization extension uses the same path for SAML-based MCP clients.

Pitfalls

XML signature handling is historically error-prone; rely on a vetted library, never hand-roll validation.
Validate signatures, audience, and conditions; misconfigured SAML has produced serious authentication bypasses.
IdP-initiated SSO has no InResponseTo to check, so it is more exposed to replay and login CSRF. Disable it where the SP does not need it.
Local login next to SAML: making SSO mandatory is a separate setting in most apps, and owner or admin accounts often keep a password. See SSO enforcement and local login bypass.
Certificate rollover: IdP signing certificates expire. Publish and consume metadata so rollovers do not become outages.

How it works, message by message

The SAML 2.0 message-flow walkthrough decodes a real-shaped <AuthnRequest> and signed <Response> field by field, maps each element to its section in SAML Core, Bindings and Profiles, and turns the validation list above into eight checks with the CVE each one prevents. Paste your own messages into the SAML decoder to compare.

Guide: SAML vs OIDC, SSO implementation. Glossary: SAML, federation. CVEs: identity CVE catalog, including ruby-saml 2024, GHES encrypted assertions, Keycloak 2024.

Who wrote it

Most of the technical editing of SAML 2.0 was done by Scott Cantor, who also architected Shibboleth. Eve Maler was a co-author of the SAML specifications. More in the experts directory.

SAML 2.0