SAML Has a Terrible Security Record — So Why Must B2B SaaS Still Support It?

Security research firm Trail of Bits has long been a vocal critic of SAML (Security Assertion Markup Language), and their core argument is sharp: this identity authentication protocol, born in the XML era, has an abysmal security track record. Yet for teams building enterprise SaaS, reality is far more complicated — the criticism is valid, but you still can't avoid it.

SAML's Security Record Is Genuinely Bad

Trail of Bits isn't crying wolf. SAML is built on XML Signature and XML parsing — two areas with historically high concentrations of security vulnerabilities. XML Signature Wrapping (XSW) attacks, XML External Entity (XXE) injection, and various assertion tampering exploits caused by inconsistent parser behavior are all recurring classics in the SAML ecosystem.

The root cause lies in the protocol's design. SAML requires implementers to parse complex XML documents while simultaneously verifying signatures. The semantic gap between signature verification and document parsing leaves a wide attack surface. A carefully crafted SAML response can pass signature validation while being interpreted as an entirely different identity assertion during subsequent processing. This class of vulnerability has appeared in implementations from major identity providers including Okta and OneLogin.

By contrast, OAuth 2.0 and OpenID Connect (OIDC) are built on JSON and JWT — a smaller protocol surface, a cleaner binding between signatures and data, and a significantly reduced attack surface overall. From a purely technical standpoint, no one starting a new project today would voluntarily choose SAML.

XML Signature Wrapping (XSW) deserves a closer look. A SAML response is structured as an XML document that contains both a signed assertion and the signature itself. An attacker can inject a forged assertion node into the document without invalidating the signature, then relocate the original legitimate node to a position outside the signature's scope. Because many implementations reference the original node during signature verification but process the attacker-injected node when reading identity information, the two steps are operating on different data — the signature check passes, but the identity that actually takes effect has been tampered with. The fundamental cause is the ambiguity of node references under XPath semantics in XML documents. JSON/JWT has no such structural problem: the signature covers the entire payload with no room for selective coverage.

So Why Support It at All?

The answer has nothing to do with technical merit — it's about the realities of the enterprise market. SAML is the de facto lingua franca of enterprise single sign-on (SSO). The IT departments of countless mid-to-large enterprises have built their identity infrastructure — Active Directory Federation Services, legacy Okta configurations, various enterprise IdPs — around SAML.

For B2B SaaS vendors, "SAML SSO support" is often a hard prerequisite for making it onto an enterprise procurement shortlist. Enterprise security teams evaluating vendors frequently list SAML integration as a pre-condition for compliance and purchasing. Refusing to support SAML effectively means walking away from a large segment of high-value enterprise customers — a commercially untenable position.

In other words, SAML's staying power doesn't come from how good it is, but from massive installed-base deployments and enterprise procurement inertia. This is a textbook case of technical debt sustained by market momentum.

Active Directory Federation Services (AD FS) is the key context for understanding enterprise SAML lock-in. AD FS is Microsoft's federated identity service bundled with Windows Server, allowing enterprises to expose internal Active Directory user accounts to external SaaS applications via SAML. Given Active Directory's dominance in enterprise IT, a huge number of mid-to-large companies have built their SSO infrastructure directly on AD FS — often running for years and deeply integrated into internal systems. Migrating this infrastructure carries enormous costs, requiring coordination across IT, security teams, and compliance reviews. Even though more modern alternatives exist (such as Azure AD's OIDC support), large volumes of AD FS deployments remain in place. This explains why even as next-generation IdPs like Okta and Azure AD have fully embraced OIDC, enterprise buyers still explicitly require SAML support in their RFPs.

How to Support SAML While Managing the Risk

Given that support is mandatory, the question becomes: how do you keep SAML's XML risks from contaminating your codebase? The core approach is to isolate SAML processing — and never write your own XML parsing or signature verification logic.

Use Mature, Purpose-Built Libraries or Gateways

Implementing SAML yourself is almost guaranteed to introduce vulnerabilities. The safer approach is to rely on thoroughly audited, mature libraries, or to completely outsource SAML handling to a dedicated identity gateway service. These solutions consolidate the error-prone XML signature validation logic in one place, maintained and patched by a specialized team.

Perform Protocol Translation at the Boundary

The ideal architecture places an authentication adapter layer at the system boundary. This layer handles all SAML interactions with enterprise IdPs and then internally translates everything into a more modern, secure token format (such as an OIDC ID Token or an internally issued JWT). With this approach, your application's core business logic never directly touches SAML XML — the complexity and risk of XML are locked inside a small, controlled box.

This architectural pattern is sometimes called an "authentication proxy" or "identity gateway." Mature open-source and commercial implementations are available for reference — for example, Keycloak (open source), Auth0, or identity services from major cloud providers. Keycloak's typical deployment model illustrates this pattern well: it acts as a middle layer that can accept upstream SAML IdPs while issuing OIDC tokens to downstream applications, keeping the application side completely unaware of SAML's existence. For teams without sufficient security engineering resources to maintain their own SAML parsing logic, fully outsourcing this complexity to a professionally audited identity service is the most pragmatic risk control available today. One important caveat: even when using an external gateway, you still need to monitor whether that gateway's own SAML implementation is tracking security patches. In 2023, GitLab suffered a serious authentication bypass vulnerability due to a flaw in the ruby-saml library — a reminder that supply-chain risks at this layer cannot be ignored.

Strict Validation and Minimal Trust

Regardless of approach, always apply strict validation to SAML responses: verify signature scope, validate the assertion Audience, check time windows, and pin the expected IdP certificate. Never trust any unverified field — especially attributes used for identity mapping.

Implications for Technical Decision-Makers

SAML's situation reflects a broader pattern in enterprise software: a protocol's survival depends largely on ecosystem lock-in rather than technical excellence. Trail of Bits is right in their criticism, but "the protocol is insecure" and "you can choose not to support it" are two very different statements.

The right posture isn't agonizing over whether to support SAML — it's putting effort into how to support it safely. Treat SAML as an external interface that requires strict isolation, not as an organic part of your system. For new developer-facing or consumer-facing products, prioritize OIDC. For enterprise-facing products, treat SAML as a mandatory but tightly controlled compatibility layer. That way, you can win enterprise deals while keeping security risk contained to the smallest possible footprint.