知名安全咨询机构 Trail of Bits 近期发布长篇技术研判，将企业单点登录（SSO）基石协议 SAML 定性为由委员会拼凑而成的糟糕设计，呼吁全行业启动该协议的有序退役，并全面转向 OpenID Connect（OIDC）。
这篇文章切中了整个软件工程界心照不宣的技术债死结。但在呼吁退役的声浪背后，行业必须厘清两个关键事实：SAML 的安全危机从来不是 RSA 等底层密码学被攻破，而是解析器与业务逻辑脱节带来的语义绑定失效；同时，在企业平均运行上百款云服务的现实商业重力下，任何指望一朝废弃旧协议的设想，都只能停留在象牙塔里。
签名合法却被提权：难以愈合的语义脱钩病灶
SAML（安全断言标记语言）诞生于 2002 年，由 OASIS 组织将四家商业机构提交的草案拼凑而成，并在 2005 年 3 月 1 日批准推出 SAML 2.0 标准。彼时正值 Web 2.0 兴起与企业级软件外包扩张期，耶鲁大学 CAS、高校联盟 Internet2 的 Shibboleth IdP 以及微软 ADFS 等系统相继落地，迅速确立了其工业标准地位，催生出 Okta、Ping Identity 等数百亿美元估值的身份认证巨头。
然而，SAML 将安全基石押注在 W3C 的 XML 数字签名（XML-DSig）规范与 C 语言解析库（如 libxmlsec）之上，允许对文档的局部节点进行签名与转换。这一机制埋下了二十年未能根除的原罪。
早自 2012 年 USENIX 安全顶会论文《On Breaking SAML》测试便显示，受测的 14 个主流框架中有 11 个存在 XML 签名包装（XSW）漏洞。攻击者可以在 XML 报文中伪造未签名的身份节点，同时把带有合法签名的节点挪到别处。校验模块在签名树上查验无误返回成功，而后端的业务代码却在消费伪造的身份节点，直接造成任意身份登录。
这一逻辑漏洞并未随着时间推移而绝迹，反而在现代主流产品中反复上演：
- CVE-2024-45409.Ruby-SAML 因 XPath 选择器与校验逻辑不一致导致任意认证绕过；
- CVE-2024-6800.GitHub Enterprise Server 因签名包装缺陷被网络攻击者直接获取管理员权限；
- CVE-2024-8698.开源身份管理平台 Keycloak 因签名位置判定错误出现提权漏洞；
- CVE-2025-29774（代号 SAMLStorm）：Node.js 生态的 xml-crypto 库因摘要校验与签名校验对 XML 注释的解析存在细微差异，使攻击者在不破坏外层签名的情况下完成越权；
- CVE-2025-27773.SimpleSAMLphp 甚至出现因 HTTP 重定向重复参数导致验证逻辑完全失效的高危漏洞（CVSS 8.6）；
- 2026 年新发缺陷.开源身份方案 authentik 同样再次被曝出签名包装攻击面。
SAML 的溃败不是数学的崩溃，而是报文过于庞杂导致的语义错位。
上述攻击充分表明，开发团队面对长达数百页的 SAML 规范及错综复杂的 XML 规范化规则，极难保证所有环节对同一份文档的解释完全一致。
百款应用构成的商业重力场：为何企业弃而难舍？
既然架构缺陷如此显著，为何企业至今无法与 SAML 切割？
首要原因在于标准的合规惯性与存量规模。Trail of Bits 的呼吁属于行业安全主张，并非官方废弃决议。截至目前，OASIS 与 IETF 均未发布任何正式的废弃时间表，SAML 2.0 依然是受官方承认的工业标准。
更深层的阻力来自 B2B 软件采购的庞大生态。根据 Okta 发布的《Businesses at Work》报告，受调企业平均部署的应用数量已从 2024 年的 93 款增至 2025 年的全球平均逾 100 款，其中美国企业平均部署量更达到 114 款。跨国机构的内部网络往往连接着数十家传统 SaaS 供应商、外包系统和政府遗留身份库，这些资产普遍仅提供 SAML 接口。
即便是主导现代技术路线的云巨头，也采取了务实的双轨策略。微软在官方身份架构指南中，明确将 OIDC 推荐为新应用构建的首选，但同时着重强调对现有存量应用与遗留 IdP 必须保留 SAML 联合支持。AWS IAM Identity Center 等核心云权限治理系统，至今依然把 SAML 视为最关键的企业联合认证载体。
SAML 的商业存量与行业分工如下表所示：
| 参与方类别 | 核心态度与动作 | 核心技术诉求与限制 |
|---|---|---|
| 安全激进派 (Trail of Bits 等) | 呼吁强推 OIDC，设立废弃日程 | 拒绝继续维护脆弱的 libxmlsec 及复杂规范化代码 |
| 云服务平台 (Microsoft / AWS) | 维持双轨并行，新旧分流 | 兼容大客户现有存量软件，保护既有采购合规 |
| 存量企业 IT (超 100 款应用) | 被动修补，延缓重构 | 替换旧系统涉及跨组织契约，迁移工程成本过高 |
对企业首席信息安全官（CISO）而言，全面推翻 SAML 绝不仅是一次协议切换，它牵扯到数十家上下游供应商的采购合约变更与配置审计。在缺乏绝对经济收益驱动的前提下，没有企业愿意外科手术式地切断既有连接。
切换至 OIDC 并非解药：协议战场的风险位移
在批评 SAML 的同时，不少开发者往往将 OpenID Connect（OIDC）奉为消除隐患的解药。这种判断忽视了协议更替的本质——攻击面重构。
OIDC 基于 JSON Web Token（JWT），将签名与有效载荷严格分离，彻底摆脱了复杂的 XML 规范化难题，天然规避了节点重排与签名包装攻击。然而，OIDC 把安全责任转嫁给了网络交互环境与应用层的状态管理。
如果开发者未严格执行 IETF 推出的 RFC 9700（OAuth 2.0 安全最佳实践），OIDC 同样会产生严重隐患。例如，未强制启用 PKCE（代码交换证明密钥）会导致授权码被中间人窃取；缺乏对颁发者（iss）和受众（aud）的多租户严格校验，会引发跨租户令牌置换；松懈的重定向 URI 白名单配置则极易被用于重定向劫持。
- 风险.若将安全希望全盘寄托于向 OIDC 的协议切换，而忽视了 RFC 9700 规定的生命周期与密钥轮换校验，系统只会从 XML 的解析陷阱跌入 OAuth 的配置泥潭。
面对无法立刻拆除 SAML 存量系统的现实，成熟工程团队的突围方向不是冒进地全量替换，而是推行收敛隔离与双轨归一：
- 边界隔离收敛业务系统不再各自嵌入不可控的 SAML 解释库，而是统一通过内部身份网关终结外部 SAML 断言，阻断解析器差异；
- 强制严格语义约束在网关注册处限定严格的消息结构模版，坚决丢弃所有带有注释、非必要扩展属性及非预期命名空间的冗余载荷；
- 内网下沉为 OIDC在网关内部完成严格校验后，将身份信息换发为合规的 JWT 传递给内层微服务，把暴露面限制在极小的网关边界内。
在这场旷日持久的企业架构博弈中，真正值得关注的指标并非某一两份檄文的呼喊，而是云厂商何时在采购规范中放宽对 SAML 的强制依赖，以及工业界能否提供无缝抹平语义差别的自动化网关工具链。