Security Assertion Markup Language, or SAML, remains widely used for enterprise single sign-on because it gives an identity provider a standard way to tell a service provider that a user has authenticated. The service provider can then make an access decision without managing the user’s original credentials. That separation is useful for organizations operating many cloud applications, but it also makes the correctness of the assertion exchange critical: a forged or misinterpreted assertion can become an authentication bypass.
Trail of Bits argues that SAML’s central weakness is not merely one historical bug. The protocol is built on XML, a flexible format with namespaces, attributes, comments, schemas, CDATA sections, and other constructs that implementations must parse consistently. Its security depends on XML signature validation, canonicalization, and agreement between the identity provider and service provider about which data the signature covers. The essay identifies signature-wrapping attacks, parser differentials, and canonicalization errors as recurring examples of how two implementations can disagree about the meaning of the same message.
This figure directly supports the article’s explanation of XML signature validation and canonicalization failures.
The distinction between a protocol flaw and an implementation flaw matters. SAML defines a broad set of messages, bindings, and profiles, while real deployments usually use only a subset. That can leave unused specification surface in libraries and configuration code, but it does not prove that every deployed implementation is vulnerable. A product can support SAML securely only if it validates signatures, audience and recipient restrictions, timing, issuer identity, and the precise signed assertion according to the relevant deployment policy. The supplied material does not establish that all SAML products fail those checks.
The essay also criticizes SAML’s enveloped signatures, in which the signature element is placed inside the XML assertion being signed. It contrasts this with the detached signature structure commonly associated with JSON Web Tokens, while acknowledging that moving to another token format does not automatically remove validation problems. OIDC relies on a larger family of specifications and implementations, and the packet does not provide enough primary evidence to compare its real-world vulnerability rate with SAML’s. Claims that OIDC is categorically safer therefore remain an argument to investigate, not a demonstrated conclusion.
This comparison illustrates the article’s discussion of enveloped SAML signatures and their contrast with JWT signatures.
For operators, the more useful question is whether their deployment has a narrow, well-tested configuration and a maintained library. Trail of Bits suggests rejecting unexpected message shapes and avoiding unnecessary protocol features where possible. Organizations should also inventory every identity provider, service provider, custom connector, and legacy integration that accepts SAML assertions, then verify how each one handles signatures and parser edge cases. A migration project should preserve those controls rather than treating a protocol change as a substitute for secure configuration.
OIDC may be a reasonable alternative for new web integrations, particularly where its authorization-code flow and back-channel communication fit the architecture. However, the supplied evidence does not show that it supports every SAML deployment pattern equally, nor does it establish a universal migration path. Teams with IdP-initiated flows, disconnected network assumptions, or specialized enterprise requirements need to test compatibility explicitly. Supporting both protocols may be necessary during a transition, but each supported protocol adds configuration and validation work.
The broader lesson is that authentication protocols age through both their specifications and their implementations. SAML’s longevity reflects genuine interoperability and deployment value; it does not make its complexity harmless. Conversely, identifying repeated XML and signature-processing failures does not justify claiming that every SAML login is unsafe. Security teams should treat the protocol as a risk-bearing dependency, reduce unnecessary flexibility, keep libraries current, and require evidence that the exact deployed flow has been tested against known parser and signature attacks.