Trail of Bits argues SAML should be retired in favor of OpenID Connect

A call to retire SAML

Trail of Bits has published an essay arguing that SAML, the XML-based protocol that still underpins much of enterprise single sign-on, should be deprecated. The piece, which reached the Hacker News front page after its September 21, 2026 publication, frames the protocol's long history of security problems not as a series of implementation mistakes but as the inevitable output of a flawed design — one the author sums up in the title's phrase, a fractal of bad design. The recommended replacement is OpenID Connect (OIDC).

How SAML became the enterprise default

According to the post, SAML emerged in 2002 from the OASIS Security Services Technical Committee, which folded four competing XML security specifications into a single standard: S2ML from Netegrity, AuthXML from Securant, X-TASS from VeriSign, and ITML from Jamcracker. That committee-driven merger, the author argues, produced a protocol that tries to do everything at once and carries the marks of a big-design-up-front process.

Adoption started in academia. The post points to Yale's CAS (2002), Internet2's Shibboleth identity provider (2003), Microsoft's ADFS (2003), and simpleSAMLphp from Norway's Uninett (around 2007) as the proving ground. Commercial vendors followed and, in several cases, built businesses on the protocol: Ping Identity (2002), OneLogin (2009), Okta (2009), and Duo Security (2010). The author writes from inside that history, having worked on Duo's first on-premises access gateway, which was itself built on simpleSAMLphp.

The XML foundation

The central technical claim is that SAML's security reduces to XML signature validation, and that this is far harder than it sounds. The post quotes security researcher Thomas Ptacek, who wrote in 2023 that SAML works only "if you assume XML signature validation is reliable," and noted that most deployed implementations end up wrapping libxmlsec, described as a "gnarly" C codebase that "nobody reads."

Even before a library reaches SAML-specific logic, the author writes, it has to survive XML's own bug classes: XXE, entity expansion (the "billion laughs" attack), DTD retrieval as an SSRF vector, and injection issues spanning XPath, XQuery, XInclude, XSLT and CDATA. On top of that sits the format's sheer complexity — namespaces, schemas, DOCTYPEs, attributes, comments — compared with JSON's small set of concepts. The author's contention is that complexity and security pull in opposite directions.

To be fair, the post concedes XML was a defensible choice at the time: JSON had only appeared in 2001, while the SAML committee was already meeting, and a standards body was unlikely to bet on an unproven format.

Signature wrapping and canonicalization

The essay treats XML signature wrapping (XSW) attacks as SAML's defining weakness. Research into signature wrapping appeared in 2005, 2008 and 2009, and the 2012 paper "On Breaking SAML: Be Whoever You Want to Be" turned the theory into an automated way to test for these attacks — work the author's team treated as a guiding reference when building Duo's gateway. Despite being understood for well over a decade, the post says, XSW remains a live problem today.

A related failure mode is canonicalization, the process of reducing XML to a consistent byte representation so signatures can be computed and verified. Canonicalization bugs enabled Kelby Ludwig's 2018 XML comment bypass, and the post links canonicalization to parser differential and round-trip bugs, which it describes as the basis of most modern SAML attacks. It cites coordinated disclosures of XML round-trip flaws in Go's standard library in 2020 and 2021 research on securing XML implementations across the web as evidence that the problem is ecosystem-wide rather than specific to any single SAML product.

What the post proposes

In total, the author identifies five flaws considered fatal to SAML's long-term viability, with the XML foundation and canonicalization serving as illustrations of the pattern. The list is also offered as a design aid: anyone writing a new authentication protocol can either steer around each flaw or deliberately build in its opposite. The conclusion is a straightforward call to deprecate SAML and standardize on OIDC for new work.

Why it matters

SAML remains the connective tissue of enterprise SSO, and, as the post's own history shows, a multibillion-dollar identity industry grew up around it. If the argument holds that its bug classes are structural consequences of XML rather than correctable implementation errors, then the practical question for identity teams is no longer whether new integrations should use OIDC, but how quickly legacy SAML can be wound down — a migration the protocol's ubiquity in corporate IT guarantees will be slow. For protocol designers, the essay doubles as a cautionary checklist of failure modes to avoid in whatever comes next.