SAML: A fractal of bad design

The Security Assertion Markup Language (SAML) protocol originated in academia and corporate IT departments, evolving as a solution for users to authenticate across numerous web services, driven by the rise of Software-as-a-Service (SaaS). The complexity of SAML stems from its foundation on XML, which introduces significant challenges related to security validation, exemplified by vulnerabilities like XML signature wrapping (XSW) and inherent issues with XML's complexity compared to alternatives like JSON. Development was characterized by a committee-based design process, leading to "kitchen-sink" protocol design that incorporated various standards. Security research began to exert pressure, notably through the identification of XSW attacks, which prompted work on related security concepts like canonicalization and enveloped signatures. This evolution has led to the recognition of SAML's flaws—including complexity, issues with canonicalization consistency, and outdated architectural assumptions regarding transport and network topologies—ultimately pushing the industry toward modern alternatives like OpenID Connect (OIDC).

The narrative traces a clear trajectory from an early, committee-driven effort to define protocols to a modern critique focused on agility and modern cryptographic primitives, positioning SAML as an artifact of historical constraints rather than optimal design. The consistent pattern is the tension between an established, historically significant standard that enabled massive economic impact and time-tested use cases, versus newer alternatives characterized by modularity and evolution. The focus on XML's inherent complexity leading to fragility in signature handling and canonicalization highlights a systemic failure where the chosen transport layer (XML) complicated security enforcement rather than simplifying it. The pattern of ossification—where SAML failed to adapt to macro-events like the rise of Zero Trust, mobile computing, and modern transport security—suggests that protocol design must account for evolving environmental assumptions, not just immediate functional requirements. This suggests a recurring challenge in standardization: balancing broad consensus with the necessity for adaptive agility in rapidly changing technical landscapes. The implications point toward an ongoing necessity to favor protocols built on more flexible structures, like JSON and JOSE, which inherently accommodate the dynamism required by contemporary security needs, over frameworks built around monolithic markup languages.