安全断言标记语言（SAML）认证协议在许多组织中仍占据主导地位，但其复杂性正逐渐成为负担。随着软件即服务（SaaS）公司的兴起，IT 部门需要一种方式让用户对众多新的网络服务进行认证，SAML 与蓬勃发展的单一登录（SSO）产业曾满足了这一需求。然而，鉴于其自身的设计缺陷与安全挑战，业界开始呼吁放弃 SAML，转向 OpenID Connect (OIDC) 等现代替代方案。本文将探讨 SAML 的“由委员会设计”起源、其在学术和企业环境中的演变，以及它在安全研究社区审视下缓慢解体的过程。
SAML 和 SSO 行业的诞生
根据维基百科定义，SAML 是一种基于 XML 的标记语言，用于安全断言。它于 2002 年由结构化信息标准发展组织 (OASIS) 的安全服务技术委员会 (SSTC) 创建。尽管 XML 具备一定优势，但与 JSON 等较新替代方案相比，其复杂性较高。此外，小组委员会会议往往导致“厨房水槽”式的协议设计（如瀑布式开发、前期大设计等）。最终，四个基于 XML 的安全协议被整合到一个规范中：
……以下知识产权已贡献给 SSTC：来自 Netegrity 的安全服务标记语言（S2ML）、来自 Securant 的 AuthXML、来自 VeriSign 的 XML 信任断言服务规范（X-TASS）、来自 Jamcracker 的信息技术标记语言（ITML）—— SAML：历史
这种协议统一的愿望在当时是迫切的。随着互联网从 90 年代的 Web 1.0 过渡到早期的 Web 2.0，用户和组织需要一个简单的方法来验证许多新的 Web 服务。学术界是这一运动的主要推动者：耶鲁大学在 2002 年推出了中央身份验证服务 (CAS)，互联网2（Internet2，一个包括作者母校的研究型大学联盟）在 2003 年推出了 Shibboleth IdP，微软也在 2003 年发布了 ADFS。这些认证项目最终以某种方式支持了 SAML。正如早期的 ARPANET 一样，大学处于互联网发展的最前沿，也是网络服务的早期消费者。一旦建立了协议可用性和新兴学术试验的基础层，商业产业便将其带走，发展为数十亿美元的产业。
SSO、身份和身份验证提供商行业也在早期起步，但直到几年后才真正实现爆发：Ping Identity (2002)、OneLogin (2009)、Okta (2009) 和 Duo Security (2010)。除了 Duo 在 2015 年才推出第一款 SSO 产品外，这些公司基本上都基于 SAML 协议构建。Duo 的第一个本地访问网关产品 (DAG) 让开发者深入接触了 SAML 协议及其冗长的规范。虽然 XML 评论绕道等问题后来才被广泛讨论，但当时 SSO 和身份验证提供商行业正处于蓬勃发展阶段。
基础中的裂痕
XML 签名包装 (XSW) 攻击被视为 SAML 的致命弱点。虽然早在 2005 年、2008 年和 2009 年就有针对签名包装和 SAML 的安全研究，但 2012 年的论文《破解 SAML：成为你想成为的人》被认为是该领域的里程碑。该论文测试了理论与实践的对比，并导致了一种检查 XSW 攻击的自动化方法的出现。这也是当时选择 simpleSAMLphp 作为构建块的原因。尽管 PHP 当时的安全记录并非完美，但 simpleSAMLphp 在 XSW 概念普及之前就已对其进行了适应。
尽管 XSW 在 2012 年的论文中占据了核心位置，但此类问题至今仍然存在。如果已知错误类别，为何难以彻底修复？在深入探讨 SAML 的具体缺陷之前，必须首先审视其摇摇欲坠的基础：XML。
在缺乏安全记录方面，XML 并非一帆风顺。许多在 90 年代对开发者来说更为熟悉的错误类别今天仍然存在于 XML 中：XXE、实体扩展（如“十亿笑”攻击）、DTD 检索（SSRF）、XPath/XQuery/XInclude/XSLT/CDATA 注入等。一个 SAML 库不仅需要处理真正的 SAML 功能，还必须应对所有这些复杂的错误类别。
除了安全漏洞类，XML 与 JSON 相比还存在显著的复杂性差异。XML 涉及标签、元素、属性、注释、命名空间、标记与内容、模式、CDATA、DOCTYPE 等众多概念；而 JSON 基本上只包含键、值、对象和列表。这种复杂性使得 SAML 成为一个设计不良的“碎形”结构。
五个致命的设计缺陷
SAML 为学习协议设计提供了反面教材。以下是五个被认为对 SAML 作为身份验证协议的长期可行性构成致命威胁的缺陷，这些教训也可用于指导新协议的设计。
1. 建立在 XML 之上
如前所述，SAML 建立在 XML 基础之上，而 XML 本身极其复杂。这并非完全归咎于委员会，因为当时人们普遍使用 XML。JSON 在 2001 年被“发现”，恰好与 SAML 委员会开会的时间重合，但当时 Java 生态系统的盛行使得 XML 成为主流。虽然可以通过量化指标（如规范/RFC 字数）来比较 XML 与 JSON 或 SAML 与 JWT/OIDC 的复杂度，但这足以说明 XML 比 JSON 复杂得多，而现在业界已有更好的选择。
2. 规范化难题
当需要将混乱的 XML 数据计算为一致的结果时，规范化至关重要。如果服务提供商 (SP) 和身份提供者 (IdP) 不能在 XML 数据的一致表示上达成一致，字节将无法排列，签名将不匹配，身份验证随之失败。然而，说起来容易做起来难。
2018 年，Kelby Ludwig 发现的 XML 评论绕过正是源于规范化错误。规范化通常是解析器差异和“往返转换”错误的前体，大多数现代 SAML 攻击都利用了这一点：
- Go 标准库中 XML 往返转换漏洞的协同披露（2020）
- 在网络上保护 XML 实现 (2021)
- 滥用 libxml2 怪癖来绕过 GitHub 企业上的 SAML 认证 (2025)
- 用任何人的身份登录：通过解析器差异绕过 SAML SSO 认证 (2025)
- SAML 轮盘：黑客总是赢 (2025)
- 脆弱锁：SAML 身份验证的新型绕过方法 (2025)
3. 封装签名机制
封装签名问题是规范化的近亲。简而言之，当试图将签名插入正在签署的数据负载中时，风险便产生了。对比 JWT 和 SAML 的签名方式可以看出差异：在 JWT 示例中，签名从 JSON 有效载荷中脱离，并在 JWT 中用点 (.) 分隔；而在 SAML 示例中，签名元素被直接插入（enveloped）在断言元素中。问题在于，当同时修改数据时，尤其是在像 XML 这样具有复杂格式和严格规范化规则的情况下，很难保证字节对字节的一致性。
4. “厨房水槽”式设计
这种设计缺陷违背了 YAGNI（You Aren't Gonna Need It）原则。虽然 SAML 规范在现实世界中使用的部分在过去 20 年里发生了变化（例如 SOAP 和 Artifact 绑定已不再常用），但事实上，99% 的现代 SAML 实现仅使用了规范中非常相似的数据形状和子集。任何今天在野外遇到的 SAML 认证都可能避免了 90% 的规范内容。这意味着大部分未使用的功能增加了相当大的复杂性。托马斯·普塔塞克曾指出，他会考虑拒绝任何与 Okta, OneLogin, Google 或 Shib 生成的标准形状不相同的消息。
5. 骨化与时代错位
SAML 是在不同的时代设计的，且未能得到必要的更新。这些担忧通常是实际存在的，而非理论性的。“骨化”主要体现在以下几个方面：
- 传输独立性 vs HTTP 假设： OIDC 假设使用 HTTP，而 SAML 是传输独立的。虽然 SAML HTTP 绑定存在且最常用，但它们并非必需。这提供了一定灵活性，但也意味着灵活性必须在某处实现并可能包含错误。SAML 诞生于 HTTP+TLS 尚未成为 Web 服务通信主导支柱的时代。HTTPS 允许 OIDC 将加密和可信通信委托给传输层。
- 网络拓扑假设： OIDC 通常假设连接的网络拓扑，而 SAML 则没有。最常见的 OIDC 流（授权代码流）假设 OpenID 提供商 (OP) 和依赖方 (RP) 可以直接通信。虽然 OIDC 也有隐性流与表单后响应，但如今已非常罕见。同样，SAML 具有直接通信的 Artifact 绑定，但也极为罕见。关键在于，如果 OP 和 RP 可以直接沟通，就减轻了验证响应负载的压力，因为所有做出验证和授权决定所需的信息都在负载中。这减少了有效载荷的大小和复杂性。相反，OIDC OP 和 RP 可以通过后台通道交换信息。
- 有机增长 vs 预先设计： OIDC 在过去几年里有机增长，而 SAML 在很大程度上是预先设计的。OIDC 包含几十规范和 RFC，多年来为解决特定需求而逐步完善。这与敏捷方法类似，而 SAML 更像瀑布式开发。非详尽的时间表显示：OpenID Connect 1.0 规范公布于 2014 年；JWS/JWE/JWK/JWA/JWT 堆栈通过 RFC 7515-7519 (2015) 完成；PKCE 通过 RFC 7636 (2015) 发布；移动/原生应用的 PKCE 通过 RFC 8252 (2017) 发布；物联网设备的设备授权流通过 RFC 8628 (2019) 发布；MFA 工作流的持有证明 (DPoP) 通过 RFC 9449 (2023) 发布；SPA 的 PKCE 通过 RFC 10017 (2026) 发布。
历史背景也很有趣。例如，SAML 成熟于 VPN 和网络细分时代，因此上述第 (2) 点尤为重要。如果 IdP 或 SP 位于企业防火墙后面，无法直接与另一端通话，SAML 需要无状态地解释这种情况。2014 年，Google 的 BeyondCorp 模式和零信任架构颠覆了这一概念。此外，SAML 未能预见移动、SPA 和物联网的革命。尽管 SAML 在企业环境中仍被广泛采用，但这些宏观事件加速了该协议的漫长衰落。在不断变化的 IT 环境中，灵活性和松散耦合使得快速适应成为可能。
所有道路通向 OIDC
没有任何协议是完美的，但在解决方案层面，所有道路都通向 OIDC。据观察，SAML 唯一具有优势的部署场景是 SP 和 IdP 无法直接通信的网络。OIDC 的隐性流与表单后响应提供了所有相同的组件。这实际上是目前行业内最清洁的迁移计划之一。
对于希望融入 SSO 生态系统的服务提供商 (SP)，最简单的策略是直接支持 OIDC，抛弃 SAML。Fly.io 和 Tailscale 已经在践行这一理念。托马斯·普塔塞克在 2024 年指出：“我们已经设法保持 OIDC 的线路。Tailscale 也是。如果 Tailscale 能坚持下去，考虑到他们的客户群体，真的试着避免使用 SAML。记住，作为一个供应商，你经常与那些根本没有真正 SSO 集成的公司竞争。”
对于希望离开 SAML 的身份或身份验证提供者 (IdP)，这可能是一条漫长的道路，取决于客户数量。策略可以是分步实施：制定废弃计划，向客户传达，停止将新客户纳入 SAML 集成，为现有 SAML 客户提供同等的 OIDC 配置，设定截止日期并开始执行。
SAML 在过去的 25 年里取得了显著成就。它诞生了 SSO 行业，帮助无数身份验证更加安全，改善了数十个 Web 服务的用户体验。我们应该感谢 SAML 协议的创造者，它为我们在技术行业动态变化时期的协议设计和演变提供了一个极佳的案例研究。
