SAML: A fractal of bad design
SAML, the XML-based single sign-on standard widely used in enterprises, is increasingly criticized as overcomplicated, insecure, and a product of design-by-committee that’s hard to implement correctly. Commenters contrast it with OAuth2/OpenID Connect and JWT, which are seen as simpler and safer, yet still imperfect and burdened by their own ecosystem and business incentives like the “SSO tax.” Many argue that while SAML persists due to enterprise inertia and legacy IdPs, new products should prefer OIDC where possible and treat SAML as legacy tech to be phased out.
Enterprise demand vs vendor choice
- Many argue enterprise products must support whatever SSO their customers use (often SAML); otherwise they are simply not viable.
- Others counter that vendors are not obligated to adopt protocols they consider insecure; losing such customers is a business decision, not an obligation.
- Some vendors report they went OIDC‑only and, in practice, most “SAML customers” were fine switching because their IdPs already supported OIDC.
- Economic angle: SAML features are often paywalled (“SSO tax”), with vendors charging thousands to “flip the switch,” justified by support and maintenance costs.
SAML vs OIDC/OAuth2/JWT
- Broad agreement that SAML is more complex and fragile than OAuth2/OIDC and JWT, though OAuth2/OIDC/JWT also have non‑trivial pitfalls.
- Debate over whether “OAuth2 is shite” stems from misuse as authentication instead of authorization; OIDC is framed as the proper authN layer.
- Some claim SAML will likely outlive OIDC due to enterprise inertia; others advocate treating SAML like an obsolete legacy (e.g., IE6) to be phased out.
Security and implementation pitfalls
- SAML’s XML signatures are a major focus: signatures can cover attacker‑chosen subsets, rely on canonicalization, and are vulnerable to XML Signature Wrapping.
- Many implementations historically validated a signature, then trusted the entire document, or misused XML‑sig libraries (e.g., HMAC with attacker‑provided keys, WebPKI validation).
- JWT/JOSE problems discussed:
alg:none, algorithm confusion, mixing symmetric and asymmetric keys. Still, many participants view JWT issues as fewer and easier to mitigate than SAML’s.
IdP‑initiated vs SP‑initiated flows
- Some defend SAML for IdP‑initiated SSO and “security baked into the payload,” especially in enterprise portal scenarios.
- Others note IdP‑initiated flows are susceptible to login CSRF; OIDC intentionally avoids them, instead using third‑party‑initiated flows that still start at the SP.
- There is disagreement over whether user confirmation prompts meaningfully mitigate such attacks.
XML, complexity, and design‑by‑committee
- Multiple comments blame SAML’s problems on XML plus design‑by‑committee: too many options for signing/encryption and extreme spec size.
- Comparisons are drawn to OSI vs IP, OpenVPN vs WireGuard, and XML vs JSON as examples where simpler, opinionated designs fare better.
Federated identity, “SSO tax,” and alternatives
- Original OpenID, OpenID Connect dynamic discovery/registration, IndieAuth, and DID/FedCM are cited as building blocks for provider‑independent identity.
- Thread consensus: business incentives (data hoarding, SSO upsell) rather than missing tech block widespread federated login.
- Some suggest that in practice SCIM inconsistencies now consume more effort than SAML vs OIDC protocol questions.