Security Assertion Markup Language (SAML) has anchored enterprise Single Sign-On (SSO) for over two decades, yet its foundational design contains fatal flaws that no software patch can permanently cure. A recent architectural analysis by security research firm Trail of Bits underscores an uncomfortable reality: SAML is not merely showing its age, but failing because its core specifications violate modern security principles.
For engineering teams managing identity providers (IdPs) and service providers (SPs), the recurring wave of authentication bypasses is not caused by careless programmers. It stems from the inherent fragility of XML canonicalization, enveloped digital signatures, and parser discrepancies. Moving away from SAML toward OpenID Connect (OIDC) is no longer just a modernization preference—it is a critical security mandate.
The Fatal Flaw of Enveloped XML Signatures
At the heart of SAML's structural instability is the XML Signature (XMLDSIG) specification. In a sensible cryptographic protocol, data is signed externally: you take an immutable binary payload, compute its cryptographic hash, and attach a detached signature alongside it. Verification is straightforward because the signed bytes never mutate.
SAML chose the opposite approach using enveloped signatures, where the digital signature element resides inside the very XML document that it purports to authenticate. To verify such a signature, the consuming application must first parse the tree, extract the signature node, strip out non-semantic variations, and re-serialize the document back into a canonical byte sequence before computing the hash.
<!-- Fragile: The signature is nested inside the assertion it signs -->
<saml:Assertion ID="_abc123" IssueInstant="2026-09-23T00:00:00Z">
<saml:Subject>
<saml:NameID>alice@example.com</saml:NameID>
</saml:Subject>
<ds:Signature>
<!-- Signature over parent assertion requires complex C14N -->
</ds:Signature>
</saml:Assertion>
This process—known as Canonical XML (C14N)—attempts to standardize whitespace, attribute sorting, namespace prefixes, and character encodings across arbitrary XML engines. Because XML is an expressive, context-sensitive tree structure rather than a flat string, building a deterministic canonicalizer has proven virtually impossible across different languages and runtimes.
Parser Differentials and XML Signature Wrapping
The gap between what the cryptographic verifier sees and what the business logic processes gives rise to XML Signature Wrapping (XSW) attacks. In an enterprise application, the security layer that checks the signature often uses one XML parser (frequently a legacy C library such as libxmlsec), while the downstream application logic that assigns user permissions uses another.
When an attacker sends a crafted SAML assertion containing duplicate nodes or unexpected wrapper elements, the signature validation engine locates and validates the genuine, signed assertion from the IdP. However, when the application subsequently inspects the document using an XPath query like //saml:NameID, it may evaluate the attacker's forged assertion instead.
Because SAML allows arbitrary transformations and complex node referencing through XPath filters, developers cannot rely on simple input validation. Decades after XSW vulnerabilities were first documented, high-profile identity providers and SaaS platforms continue to suffer critical authentication bypasses whenever edge cases emerge in their underlying XML parsers.
Why OpenID Connect Solves the Structural Problem
OpenID Connect (OIDC), built atop OAuth 2.0 and JSON Web Tokens (JWT), avoids these architectural traps by eliminating canonicalization entirely. A JWT consists of three distinct, base64url-encoded strings separated by simple dots: header, payload, and detached signature.
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJhbGljZSIsImFkbWluIjpmYWxzZX0.T7d...valid_sig
In OIDC, signature verification happens directly over the raw, unparsed ASCII bytes of header.payload. The application does not need to parse JSON objects, navigate complex nested trees, or normalize whitespace before verifying authenticity. The cryptographic boundary is completely decoupled from the data serialization format.
If an attacker tampers with a single byte in the payload, the hash changes instantly and verification fails deterministically. There is no room for parser differentials because cryptographic validation precedes object deserialization.
Practical Steps for Engineering Teams
Completely deprecating SAML overnight is challenging for organizations tied to legacy enterprise customers. However, teams can immediately reduce their attack surface through targeted architectural mitigations:
- Default to OIDC for New Integrations: Treat SAML as a legacy fallback only, requiring explicit business justification and security review for new connections.
- Isolate SAML Termination at the Gateway: Never parse raw SAML XML assertions inside downstream microservices. Terminate SAML exclusively at an identity broker (such as Okta, Keycloak, or Auth0) that translates the assertion into a standard OIDC token before routing requests internally.
- Enforce Strict Schema and Single-Assertion Constraints: When SAML must be handled directly, reject documents with multiple assertion blocks, disallow external entity resolution (XXE prevention), and avoid dynamic XPath evaluations for identity resolution.
SAML solved a critical single sign-on challenge in the early days of SaaS, but its reliance on XMLDSIG represents an obsolete design philosophy. Sunsetting SAML in favor of OIDC is not merely standard refactoring; it is closing one of enterprise IT's most durable security liabilities.
Loading comments…