Matt Schwager spent years inside Duo’s on-prem Access Gateway, which was built on simpleSAMLphp and the SAML protocol. His conclusion, 25 years after SAML shipped: it should be deprecated in favor of OIDC, and the reason is not one bad bug — it is the foundation.

SAML was designed by an OASIS committee in 2002 by merging four competing XML security protocols (S2ML, AuthXML, X-TASS, ITML) into one specification. That origin predicts the trouble.

  • It is built on XML. Before a SAML library does anything SAML-specific, it has to defend against XXE, billion-laughs entity expansion, DTD retrieval/SSRF, and injection into XPath, XQuery, XInclude, XSLT, and CDATA. Complexity and security pull against each other.
  • Canonicalization has to exist. To sign XML you must hash a canonical form of it, which means signer and verifier must agree byte-for-byte on a representation. That precondition is what generates parser-differential and round-trip bypasses — the bug class behind the 2018 XML comment bypass, Go’s 2020 XML round-trip flaws, and the 2025 GitHub Enterprise and PortSwigger findings.
  • Enveloped signatures sign data they also modify. JWT detaches the signature from the payload with a period. SAML nests the Signature element inside the Assertion it signs, so producing a canonically stable representation of data you are simultaneously editing becomes very hard.
  • Kitchen-sink design. Most real-world deployments use a narrow data shape; a typical authentication in the wild avoids the large majority of the spec. The unused surface is pure liability.
  • Ossification. SAML predates the world it now runs in: OIDC assumes HTTP and a connected topology, SAML does not; SAML was designed up front, while OIDC accreted from RFCs solving one concrete need at a time — PKCE, then PKCE for native apps, then device grants, then DPoP.

Schwager is careful about who to blame. XML was what the committee had; JSON was brand new and the room was writing Java. And SAML’s transport independence genuinely mattered in an era of VPNs and segmented networks, where an IdP behind a firewall could not talk to an SP.

That advantage is largely gone. BeyondCorp and zero trust flipped the assumption in 2014, and SAML never answered mobile, SPAs, or IoT.

His migration advice splits by role. If you are a service provider: support OIDC, stop adding SAML — Fly.io and Tailscale have held that line. If you are an identity provider: plan the deprecation, stop onboarding new SAML customers, offer equivalent OIDC configurations, set a sunset date. The essay’s framing is gratitude, not contempt — SAML birthed the SSO industry — but the practical read for anyone integrating SSO today is to treat SAML support as technical debt you are choosing to take on.