Trail of Bits says it's time to retire SAML for OIDC

SAML was created in 2002 by OASIS's Security Services Technical Committee, which merged four separate proposals contributed by four different companies: Security Services Markup Language from Netegrity, AuthXML from Securant, XML Trust Assertion Service Specification from VeriSign, and Information Technology Markup Language from Jamcracker. Academia adopted it first, through projects like Central Authentication Service at Yale (2002) and the Shibboleth identity provider from Internet2 (2003), before commercial vendors built entire businesses on top of it: Microsoft's ADFS (2003), Uninett's simpleSAMLphp (around 2007), and single sign-on providers Ping Identity (2002), OneLogin (2009) and Okta (2009). Duo Security, founded in 2010, was the exception; its first SSO product, the Duo Access Gateway built on simpleSAMLphp, did not ship until 2015. The author, who worked on that Access Gateway, writes that they were present when researcher Kelby Ludwig found the XML comment bypass.

The post walks through five flaws it considers fatal to SAML's long-term viability. First, SAML is built on XML, which is inherently more complex than JSON and inherits XML's own long list of bug classes: XXE, entity expansion ('billion laughs'), DTD-triggered server-side request forgery, and injection through XPath, XQuery, XInclude, XSLT or CDATA. Second, canonicalization: the identity provider and service provider must agree on one byte-for-byte representation of the XML before hashing and signing it, and mismatches between XML parsers are behind most modern SAML attacks; canonicalization bugs specifically enabled Ludwig's 2018 XML comment bypass. Third, enveloped signatures: SAML inserts its signature inside the same Assertion element the signature covers, unlike JWT, which keeps signature and payload detached, so any canonicalization slip breaks the exact byte match the signature depends on. Fourth is what the post calls 'kitchen-sink' design: because the specification was assembled from four separate proposals, the author says 99% of modern SAML implementations converge on a similar data shape and subset of the spec, while any single real-world deployment probably ignores 90% of the full specification. Fifth is ossification: SAML is transport-independent rather than assuming HTTP, and often needs the identity provider and relying party to exchange information indirectly through the browser rather than talking to each other directly, the way OIDC's usual authorization-code flow does. OIDC itself grew through a sequence of separately published specifications rather than one upfront design: OpenID Connect 1.0 in 2014, the JOSE stack via RFC 7515 through 7519 in 2015, and PKCE via RFC 7636 in 2015, with further PKCE work for mobile and native applications following.

The post backs its argument with a dated research timeline: signature-wrapping papers in 2005, 2008 and 2009, SAML-specific security research in 2008, then the 2012 paper 'On Breaking SAML: Be Whoever You Want to Be,' which the author calls the field's foundational work for turning XML signature-wrapping theory into an automated, practical attack check. More recent items on the same timeline include a coordinated disclosure of XML round-trip vulnerabilities in Go's standard library (2020), 'Securing XML implementations across the web' (2021), a 2025 bypass abusing libxml2 quirks against GitHub Enterprise, the 2025 'Sign in as anyone' parser-differential bypass, 'SAML roulette: the hacker always wins' (2025), and 'The Fragile Lock' novel SAML bypasses (2025).

The piece's central claim is that SAML is being crushed under its own complexity and should be deprecated for OIDC. It quotes security researcher Thomas Ptacek twice: in 2023, saying XML signature validation is 'deeply cursed' because most fielded SAML implementations end up wrapping libxmlsec, 'a gnarly C codebase nobody reads'; and in 2021, suggesting that anyone still adding SAML support today should, beyond the standard checks, reject any message whose shape doesn't match what Okta, OneLogin, Google or Shibboleth actually generate.

Key facts

SAML was created in 2002 by OASIS's Security Services Technical Committee by merging four separate proposals from four companies: S2ML (Netegrity), AuthXML (Securant), X-TASS (VeriSign) and ITML (Jamcracker).
The author says 99% of modern SAML implementations converge on a similar data shape and subset of the spec, while any given real-world deployment probably ignores 90% of the full specification.
Canonicalization mismatches between XML parsers, behind most modern SAML attacks, enabled Kelby Ludwig's 2018 XML comment bypass and several bypasses published in 2025, including one against GitHub Enterprise.
The post argues SAML should be deprecated in favor of OIDC, partly because OIDC assumes HTTP and typically lets its identity provider and relying party communicate directly, while SAML does neither by design.
Security researcher Thomas Ptacek is quoted saying most fielded SAML implementations end up wrapping libxmlsec, 'a gnarly C codebase nobody reads.'

Why it matters

SAML still runs enterprise single sign-on more than two decades after its 2002 debut, and the post argues its XML foundation has made it structurally hard to secure rather than just occasionally buggy: canonicalization mismatches have produced a steady stream of authentication-bypass research from the 2012 signature-wrapping paper through five separate 2025 writeups. The author's case is that patching individual bugs will not fix a protocol whose signature verification depends on getting XML canonicalization exactly right, and that OIDC avoids the underlying trap by using JSON and a detached signature instead.

Who it affects

Anyone running or built on SAML-based single sign-on: IT departments and the vendors behind Okta, OneLogin, Ping Identity, Microsoft ADFS, Shibboleth, Duo and simpleSAMLphp deployments, plus the developers who maintain SAML libraries and have to handle XML's own bug classes, XXE, entity expansion, DTD-triggered SSRF, and XPath, XQuery, XInclude, XSLT or CDATA injection, before they even reach SAML-specific logic.

How to use it

The post is an argument rather than a howto, but it offers one concrete piece of advice for anyone stuck adding SAML support today: beyond the standard checks, reject any incoming message whose shape doesn't match what Okta, OneLogin, Google or Shibboleth actually generate, a suggestion the post attributes to researcher Thomas Ptacek. Its broader recommendation is to build new authentication on OIDC rather than SAML.

How solid is it

The author writes from direct experience, saying they worked on Duo Security's first on-premises SSO product, the Duo Access Gateway built on simpleSAMLphp, and were present when Kelby Ludwig found the XML comment bypass. The post backs its argument with a named research timeline running from 2005 signature-wrapping papers through five separate 2025 SAML-bypass writeups, plus two dated quotes from researcher Thomas Ptacek. It remains an opinion and advocacy piece on Trail of Bits' own blog rather than a controlled study, its specific author is not named in the retrieved text, and that text cuts off mid-sentence partway through the OIDC history section, before any closing recommendation beyond deprecating SAML.

Risks and caveats

The case leans heavily on XML's own security record, XXE, entity expansion, DTD-triggered SSRF, and XPath, XQuery, XInclude, XSLT or CDATA injection, plus canonicalization and enveloped-signature issues specific to XML digital signatures. The retrieved article breaks off before its conclusion, so nothing here should be read as the piece's final word on an actual deprecation timeline or industry response.

“What's insidious about SAML is that it really is mostly straightforward to understand, but it's built on a foundation of sand, bone dust, and ash; it works, if you assume XML signature validation is reliable. But XML signature validation is deeply cursed, and is so complicated that most fielded SAML implementations are wrapping libxmlsec, a gnarly C codebase nobody reads.”

— Thomas Ptacek, quoted in the Trail of Bits post, 2023