IDSync — identity software buyer platform
Run Stack Finder

Standards & Protocols

SAML 2.0 (Security Assertion Markup Language)

SAML 2.0 is an XML-based standard that lets an identity provider (IdP) issue signed assertions about a user so a service provider (SP) can sign them in without a separate password.

Last reviewed 5/30/2026

Key points

  • SAML 2.0 was ratified by OASIS in 2005 and is still the default for enterprise B2B SSO and most legacy SaaS.
  • It uses XML assertions signed (and optionally encrypted) by the IdP, delivered via the user's browser.
  • The most common flow is SP-initiated SSO with HTTP POST binding.
  • SAML is showing its age: XML signature wrapping, certificate rotation, and metadata mismatches are common failure modes.
  • For new apps, OpenID Connect is usually a better choice — but you can't avoid SAML if you sell into enterprise IT.

What is SAML 2.0?

SAML — Security Assertion Markup Language — is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). SAML 2.0, ratified by OASIS in March 2005, is the version everyone means when they say "SAML." Two decades on, it is still the dominant protocol for enterprise web SSO and B2B federation.

If you sell software to enterprises with an IT or security team, you will be asked for SAML support. If you buy software for an enterprise, SAML is how you wire it into Okta, Microsoft Entra ID, Ping, or your IdP of choice.

How SAML works

The typical flow is SP-initiated SSO with the HTTP POST binding:

  1. The user visits the application (SP).
  2. The SP sees no session and redirects the browser to the IdP's SSO endpoint with a SAML AuthnRequest.
  3. The IdP authenticates the user (password + MFA, passkey, existing session).
  4. The IdP builds a signed XML Response containing one or more Assertion elements. The assertion includes the user's identifier (NameID), attributes (email, groups, etc.), and conditions (audience restriction, validity window).
  5. The browser auto-POSTs the response back to the SP's Assertion Consumer Service (ACS) URL.
  6. The SP verifies the XML signature using the IdP's public certificate, validates the conditions, and creates a local session.

The trust anchor is a long-lived signing certificate exchanged out-of-band through SAML metadata XML files. Metadata also declares ACS URLs, entity IDs, and supported bindings.

When buyers care about SAML

You will deal with SAML when:

  • You're rolling out enterprise SSO to a fleet of SaaS apps, many of which still only speak SAML.
  • You're a software vendor selling upmarket and your buyers' procurement checklist asks for "SAML 2.0 SSO" — often gated behind an enterprise tier (the so-called "SSO tax").
  • You're federating with a partner organization (B2B) and they want to be the IdP.
  • You're integrating with on-prem or legacy systems (older HRIS, ITSM, document management) that pre-date OIDC.

SAML vs OpenID Connect

| Aspect | SAML 2.0 | OpenID Connect | | --- | --- | --- | | Token format | Signed XML assertion | JSON Web Token (JWT) | | Transport | Browser (POST / Redirect) | HTTPS API + browser | | Best for | Legacy SaaS, on-prem, B2B federation | Modern web, mobile, SPAs, APIs | | Built on | Standalone | OAuth 2.0 | | Complexity | High (XML signatures, metadata) | Lower (JSON, well-known endpoints) |

If both are offered, choose OIDC for new integrations. Choose SAML when it's the only option, which is still often.

Common pitfalls

  • Clock skew. SAML conditions include NotBefore and NotOnOrAfter timestamps. If SP and IdP clocks drift by more than a few minutes, valid responses are rejected. Use NTP and allow a small skew window.
  • Certificate rotation. Signing certs expire. If you don't rotate them on a planned schedule with both sides updated, SSO breaks for everyone at once.
  • XML signature wrapping attacks. Older SAML libraries are vulnerable to assertion-wrapping. Use a well-maintained library and reject responses where the signed element doesn't cover what you're reading.
  • NameID changes. If the IdP changes how it formats NameID (e.g. UPN vs email), users lose access to their existing accounts in the SP.

FAQ

Is SAML deprecated?

No. The 2.0 spec is stable and widely deployed. There is no SAML 3.0. New protocols (OIDC) are preferred for new work, but SAML will be alive in enterprise IT for years.

Can I do SAML without an IdP?

No — that's the whole point. You need something to issue and sign the assertions. That can be a SaaS IdP (Okta, Entra ID, JumpCloud), an open-source IdP (Keycloak, Authentik), or a federated partner.

What's the "SSO tax"?

SaaS vendors that gate SAML SSO behind their highest pricing tier, often charging multiples of the base price. It's a controversial practice — see sso.tax — and IDSync notes it in vendor profiles where relevant.

Standards & references