SAML — the Security Assertion Markup Language — was assembled in 2002 by the OASIS Security Services Technical Committee from four contributed XML security specifications: S2ML (Netegrity), AuthXML (Securant), X-TASS (VeriSign), and ITML (Jamcracker). The result is a kitchen-sink protocol designed by committee of subcommittees, built atop XML at a time when JSON was barely a concept. It became the backbone of enterprise single sign-on because universities needed federated authentication and the commercial SSO industry — Ping Identity (2002), OneLogin (2009), Okta (2009), Duo Security (2010) — was built on top of it. The core problem is structural, not incidental. SAML's security model depends on XML signature validation, which Thomas Ptacek describes as "deeply cursed." Most implementations wrap libxmlsec, a C codebase that few people read. XML itself carries a sprawling attack surface: XXE, entity expansion ("billion laughs"), DTD retrieval (SSRF), XPath injection, XSLT injection, CDATA injection, and more. A SAML library has to neutralize all of these before it even reaches SAML-specific functionality. XML signature wrapping (XSW) attacks are the protocol's defining vulnerability. The landmark 2012 paper "On Breaking SAML: Be Whoever You Want to Be" demonstrated automated exploitation, and the bug class persists thirteen years later. Six separate disclosures in 2025 alone — including bypasses in Go's standard library, libxml2, and GitHub Enterprise — confirm the fundamental unfixability. The enveloped signature design, where the signature is inserted into the payload being signed, creates an inherent tension: you cannot get byte-for-byte canonical equivalence of data you are simultaneously modifying. Canonicalization (C14N) is the second structural fault line. To verify signatures, the identity provider and service provider must agree on a canonical XML representation. This is brutally difficult given XML's complexity — tags, elements, attributes, comments, namespaces, schemas, CDATA, DOCTYPEs. Canonicalization bugs enabled Kelby Ludwig's XML comment bypass in 2018 and remain the entry point for parser differential attacks, which constitute the dominant modern SAML attack vector. The specification itself is massively over-engineered. Ninety-nine percent of real-world SAML implementations use a narrow subset of the spec; any given authentication flow avoids roughly 90% of the specification's surface area. SOAP binding and artifact binding are effectively dead features. This is textbook YAGNI — complexity that exists on paper, creates attack surface in code, and delivers zero value in practice. Meanwhile, the protocol has ossified: designed for a different era, it has received no meaningful updates to address its foundational flaws. The alternative already exists. OpenID Connect (OIDC) operates over JSON and JWT, where signatures are detached from payloads (delimited by a period), eliminating the enveloped signature problem entirely. JSON's data model — keys, values, objects, lists — is dramatically simpler than XML's. The SSO industry knows this. The migration is happening, but institutional inertia in corporate IT and academia keeps SAML entrenched. The author's credibility here is first-hand: they built Duo Security's first on-premises Access Gateway product on simpleSAMLphp, were present when the XML comment bypass was discovered, and spent years digesting the SAML specifications. The argument is not theoretical — it is an insider's call for deprecation of a protocol whose foundation cannot be repaired, only replaced.
