安全断言标记语言（Security Assertion Markup Language，SAML）诞生于学术界，在企业信息技术（IT）部门中成长，至今仍是这些组织的主力，但如今该让它退休了。随着 2000 年代末软件即服务（software-as-a-service，SaaS）公司兴起，IT 部门需要让用户登录许多新 Web 服务，SAML 和新兴的单点登录（single sign-on，SSO）行业满足了这一需求。然而，SAML 正被自身复杂性压垮，是时候弃用它，转向 OpenID Connect（OIDC）等现代替代方案。

SAML 源于学术界，成长于企业 IT 部门，至今仍是这些组织的认证标配。但如今它该退休了。本世纪初 SaaS 公司兴起，IT 部门需要让用户登录众多新 Web 服务，SAML 与刚起步的单点登录（SSO）行业满足了这一需求。然而 SAML 正被自身的复杂性压垮，应弃用并转向 OpenID Connect（OIDC）等现代替代方案。以下探讨 SAML 的委员会起源、在学术与企业环境中的演进、安全研究界的逐步瓦解，以及（希望）被新协议取代。

关于 SAML 的基础：Thomas Ptacek 在 2023 年指出：“SAML 的阴险之处在于它大体上易懂，但建立在沙、骨灰与灰烬之上；只要你假设 XML 签名验证可靠，它就能工作。可 XML 签名验证深陷诅咒，复杂到多数实地 SAML 实现只是在封装没人读的 libxmlsec 这个粗糙 C 代码库。”

SAML 与 SSO 行业的诞生

维基百科称 SAML 是“基于 XML 的安全断言标记语言”，2002 年由 OASIS 安全服务技术委员会（SSTC）创建。按现代标准，这开头就不妙：XML 虽有些优点，但比 JSON 等新格式复杂得多。而且分委员会开会注定产生“厨房水槽”式协议设计。果然，当时把四种 XML 安全协议塞进了一个：Netegrity 的 S2ML、Securant 的 AuthXML、VeriSign 的 X-TASS、Jamcracker 的 ITML。

不过这类协议的需求不可否认。90 年代 Web 1.0 转向本世纪初 Web 2.0 时，用户和组织需要简便认证多服务。学术界是主要推动力：2002 年耶鲁的 CAS、2003 年 Internet2 的 Shibboleth、同年微软 ADFS、约 2007 年 Uninett 的 simpleSAMLphp。这些认证项目后来都以某种方式支持 SAML。大学像从前的 ARPANET 一样站在前沿，成为最早消费者。学术验证基础打好后，商业 SSO 行业随之而起：Ping Identity（2002）、OneLogin（2009）、Okta（2009）、Duo Security（2010）。这些公司基本建在 SAML 上（Duo 2015 才推 SSO 产品）。作者曾开发 Duo 基于 simpleSAMLphp 的本地 Access Gateway 产品，由此熟稔 SAML 规范，并亲历 Kelby Ludwig 发现 XML 注释绕过漏洞（后文详述）。SSO 行业蓬勃，大半筑于 SAML。

防护上的裂痕

XML 签名包装（XSW）攻击是 SAML 的阿喀琉斯之踵。虽有更早研究，但 2012 年《On Breaking SAML: Be Whoever You Want to Be》是奠基之作，它从理论到实践，给出自动检测 XSW 的方法。作者团队实现网关时以此为准，选 simpleSAMLphp 正是因其抗 XSW——当时还没人清楚这漏洞。

尽管 2012 论文已凸显，XSW 至今仍存（如 PortSwigger 的 The Fragile Lock）。已知漏洞类为何修不掉？得先看 SAML 赖以生存的 XML 基础。XML 安全记录本就糟糕：XXE、实体扩展（十亿笑话）、DTD 检索（SSRF）、XPath/XSLT 注入等至今仍在。SAML 库得先处理这些才能谈功能。此外 XML 比 JSON 复杂太多（标签、属性、注释、命名空间、CDATA 等 vs 键值对），复杂性与安全相悖，这是 SAML 坏设计的一层。

基于 XML

如上，SAML 建在 XML 上。XML 是当时可用之物，JSON 虽 2001 年出现但尚实验性，委员会不可能绕开 Java 用新格式。定量比较 XML/JSON 复杂度需另写文章，但显然 XML 复杂得多。

规范化

规范化（C14N）是把杂乱 XML 统一格式再算哈希，否则 SP 与 IdP 字节对不上、签名不匹配、认证失败。但这极难做好。规范化漏洞导致了 2018 年 Kelby 的 XML 注释绕过：

规范化常引发解析器差异或“往返”漏洞，多数现代 SAML 攻击借此：2020 年 Go 标准库 XML 往返漏洞协同披露、2021 年跨 Web 的 XML 实现加固、2025 年利用 libxml2 怪癖绕过 GitHub Enterprise SAML、2025 年用解析器差异绕过 SAML SSO、2025 年 SAML roulette 与 The Fragile Lock 等。

内嵌签名

内嵌签名与规范化是近亲。若把签名插入被签数据体内，必惹麻烦。对比 JWT 与 SAML：

JWT 的蓝色签名脱离 JSON 载荷，用点分隔；SAML 的 Signature 元素嵌在 Assertion 元素内。问题是在修改数据同时难以获得逐字节规范等价表示，XML 复杂规范下更甚。

“厨房水槽”式设计

这缺陷近似“你不会需要它”（YAGNI）。真实世界用的 SAML 子集二十年来已变（抱歉，SOAP 和 artifact binding），但事实是 99% 现代实现用极相似的数据形态和规范子集，野生 SAML 认证避开约 90% 规范，为无用功能增添巨复杂。Thomas Ptacek 2021 年称，若给新东西加 SAML 支持，他会拒绝任何形状不同于 Okta、OneLogin、Google 或 Shib 生成的消息。

僵化

SAML 为旧时代设计，未获必要更新。对比 OIDC：

1. OIDC 假定 HTTP（RFC 6749），SAML 传输独立。SAML 虽有 HTTP 绑定但非必须，灵活性须明确定义且可能有 bug。SAML 诞生时 HTTP+TLS 未主导，从未调和；HTTPS 让 OIDC 把加密信任抛给传输层。
2. OIDC 通常假定连通拓扑，SAML 不假定。OIDC 授权码流需 OP 与 RP 直连，可后台信道交换信息，减载荷复杂度；SAML 的 artifact binding 直连但罕见。
3. OIDC 多年有机成长，SAML 大设计前置。OIDC 含数十规范逐年解决具体需求，类似敏捷 vs 瀑布。粗略时间线：
   • 2014 OpenID Connect 1.0 发布
   • 2015 JOSE 栈完成（RFC 7515-7519）
   • 2015 PKCE（RFC 7636）
   • 2017 移动/原生应用 PKCE（RFC 8252）
   • 2019 物联网设备授权（RFC 8628）
   • 2023 DPoP 用于 MFA（RFC 9449）
   • 2026 SPA 的 PKCE（RFC 10017）

历史背景有趣：SAML 成长于 VPN 和网段隔离时代，若 IdP/SP 在防火墙后不能直连，部署停滞，故需无缝应对。2014 年 BeyondCorp 零信任翻转此观念。SAML 未预料移动、SPA、IoT 革命，无从应答，虽在企业广泛部署，但宏观事件致其缓慢衰落。敏捷与松耦合才能快速适应。

殊途同归转向 OIDC

没有完美协议，但解法都指向 OIDC。唯一 SAML 占优场景是 SP/IdP 不能直连网络，而 OIDC 隐式表单流提供相同要素，是业界最干净迁移方案。

若你是服务提供商（SP）想免 SAML 集成 SSO，只需支持 OIDC，弃用 SAML。Fly.io 和 Tailscale 已如此。Thomas Ptacek 2024 年说：“我们至今守住 OIDC 底线，Tailscale 也是。若他们都行，多数组织也行。真尽量别做 SAML。记住作为供应商你常与不集成真 SSO 的竞品争。”

若你是身份或认证提供商（IdP）想迁离 SAML，视客户量可能是长路，但可逐步：制定弃用计划、沟通客户、停止新 SAML 接入、为现有客户提供等价 OIDC 配置、设日落日期。

SAML 良好运行 25 年，缔造 SSO 行业，保障无数认证，改善数十 Web 服务登录体验，创造数十亿经济影响。应感谢其创造者，它为我们提供了动态科技期协议设计的绝佳案例。

社区普遍反感 SAML 的 XML 包袱与委员会式复杂设计，呼吁简化或替代；但大量企业视角用户强调 SAML 在 IdP 发起流等场景仍不可或缺，并指出 OIDC 同样漏洞不少，现实需两者共存。

SAML 协议过度复杂且源于委员会式设计，理应被精简或淘汰

• 多人指出 SAML 是 XML 盲目解决一切时代的产物，为满足所有可能用例而失去专注，协议复杂性藏匿安全漏洞，对比 Wireguard、IP 等极简设计尤显笨重。（认可度：较多人） > 只要听说它是基于 XML 的，我就已经信服它该被淘汰了（@TZubiri）

企业场景里 SAML 仍有 OIDC 缺少的关键能力，应当双协议支持

• 企业用户反映 SAML 支持 IdP 发起流等窄域但必要的单点登录特性，企业 IDP 高度依赖；若产品不支持 SAML 便失去订单，而 OIDC 各产品支持参差，因此售卖企业软件需同时支持两者。（认可度：较多人） > SAML 虽糟却有 OIDC 缺失的企业 SSO 功能，最终会被取代但眼下应两者皆支持（@cameronh90）

OIDC 与 OAuth 并非完美替代，同样存在严重安全缺陷

• 多人批评原文只列 SAML 漏洞却不横向对比，OIDC 有 JWT 算法混淆、none 算法攻击、缺失受众检查等，OAuth2 实现也被称糟糕，代理身份认证更是共同难题。（认可度：较多人） > 文章只控诉 SAML 却不与 OIDC 的漏洞对比，这种比较本身有失公允（@sandeepkd）

少数派认为 SAML 在负载内安全绑定等特定点仍有价值

• 少数人辩称 SAML 签名嵌入负载可对抗 SSL 卸载环境下的中间人，且工具有效性取决于实施者技能，不应全盘否定。（认可度：少数人）

实现认证机制本身是噩梦，标准与库的糟糕实现更危险

• 开发者吐槽对接所有主流认证协议极为痛苦，OAuth2 亦差；更有旧版 XML 签名库竟接受攻击者自签证书或文档内密码，标准与实现双重溃烂。（认可度：较多人） > 曾有个 XML 签名实现会用攻击者文档里的密码做校验，甚至用其自有域 TLS 密钥签也通过，不知为何没被黑穿（@bawolff）

理想认证应轻量、由远见主导且供应商无关

• 部分意见主张应像 IP 那样只做令牌拷贝与回验的极简流程，而非堆砌协议层；当前缺少用户自控后端的独立登录方式，OIDC 也过度迎合大厂。（认可度：少数人） > 若按精简思路，登录方给个令牌靠第三方回验即可，何必弄成现在这般复杂（@pocksuppet）

有价值的补充

• 可仅实现 SAML 子集及前十供应商方言来平衡复杂度与覆盖率，小众需求按商机临时添加（@arpinum）
• 代理（agent）身份如何认证在大企业仍是空白，OIDC 在此已现裂痕（@miguelspizza）
• 实际集成中 SCIM 协议在身份提供商间的差异比 SAML/OIDC 更耗费精力（@cameronh90）
• OSI 模型虽败于 IP，但其 X.509 被借壳为 WebPKI 证书，说明复杂委员会产物常残存碎片（@pocksuppet）