SAML: A fractal of bad design

Named attacks the summary omits

The post's core argument (five flaws, deprecate for OIDC, Fly.io/Tailscale holding the line) is already in the summary. What it does not carry is the concrete attack ledger and the two actionable engineering options. Those are the reason to read further.

The page anchors "SAML is unfixable in practice" to specific, mostly-2025 disclosures — evidence that parser-differential bypasses are a live wave, not history:

• XML comment bypass (Kelby Ludwig, 2018) — canonicalization handling of XML comments let an attacker alter the asserted identity.
• XML round-trip vulnerabilities in Go's standard library (2020).
• Abusing libxml2 quirks to bypass SAML authentication on GitHub Enterprise (2025).
• "Sign in as anyone: Bypassing SAML SSO authentication with parser differentials" (2025).
• "SAML roulette: the hacker always wins" (2025).
• "The Fragile Lock: Novel Bypasses For SAML Authentication" (2025).

The through-line: nearly all modern SAML attacks are parser-differential / round-trip bugs downstream of C14N and enveloped signatures, and most implementations wrap libxmlsec (or libxml2), a C codebase the post argues nobody audits. XSW from the 2012 "On Breaking SAML" paper is still present today.

What to do

Two concrete paths the page states:

If you must keep SAML — harden by rejecting anything that doesn't look like real-world traffic. Ptacek's rule: beyond standard SAML checks, reject any message that doesn't have the same shape as what Okta, OneLogin, Google, or Shibboleth generates. The premise: ~99% of real deployments use the same narrow subset, so ~90% of the spec's surface can be refused outright.

To migrate off SAML (as an IdP) — the stated deprecation sequence:

1. Develop a deprecation plan and communicate it to customers.
2. Stop onboarding new customers to SAML.
3. Provide existing SAML customers equivalent OIDC configurations.
4. Set a sunset date, then execute.

The one deployment edge where SAML historically won — SP and IdP that cannot talk directly (network segmentation / VPN era) — is covered by OIDC implicit flow with form post, so the page claims no remaining scenario requires SAML.

Caveats

The "kitchen-sink" and "built on XML" critiques are argument, not new findings — the author concedes XML was the only reasonable choice in 2002 and that the used subset has shifted over 20 years. The hardening rule and migration plan are quoted recommendations, not a tested procedure with results.