安全断言标记语言（SAML）仍被广泛用于企业单点登录，因为它为身份提供商提供了一种标准方式，使其能够告知服务提供商用户已经完成身份验证。随后，服务提供商可以在不管理用户原始凭据的情况下作出访问决定。对于运营众多云应用的组织而言，这种职责分离十分有用，但也意味着断言交换过程必须准确无误：伪造或被错误解释的断言可能演变为身份验证绕过。
Trail of Bits 认为，SAML 的核心弱点并非仅仅源于某个历史漏洞。该协议建立在 XML 之上；XML 是一种灵活的格式，包含命名空间、属性、注释、模式、CDATA 节以及其他构造，各种实现必须一致地解析这些内容。其安全性取决于 XML 签名验证、规范化，以及身份提供商和服务提供商是否就签名所覆盖的数据达成一致。文章将签名包装攻击、解析器差异和规范化错误列为反复出现的案例，说明两种实现可能对同一消息的含义作出不同判断。
该图直接支撑文章对 XML 签名验证和规范化失败的解释。
区分协议缺陷与实现缺陷至关重要。SAML 定义了种类繁多的消息、绑定和配置文件，而实际部署通常只使用其中一部分。这可能会在库和配置代码中留下未使用的规范表面，但并不能证明每一种已部署实现都存在漏洞。产品只有在根据相关部署策略验证签名、受众和接收者限制、时间条件、签发者身份以及经过精确签名的断言时，才能安全地支持 SAML。所提供的材料并不能证明所有 SAML 产品都会在这些检查上失败。
文章还批评了 SAML 的封装签名，即签名字素位于其所签署的 XML 断言内部。文章将其与 JSON Web Token 通常采用的分离式签名结构进行对比，同时承认，改用其他令牌格式并不会自动消除验证问题。OIDC 依赖更庞大的一系列规范和实现，而现有材料没有提供足够的原始证据，可用于比较它与 SAML 在现实环境中的漏洞发生率。因此，声称 OIDC 在所有情况下都更安全的观点仍只是一个有待调查的论点，而不是已经得到证明的结论。
该对比展示了文章对 SAML 封装签名及其与 JWT 签名差异的讨论。
对于运营人员而言，更有价值的问题是：他们的部署是否采用了范围明确且经过充分测试的配置，以及是否使用了持续维护的库。Trail of Bits 建议拒绝形状异常或出乎意料的消息，并在可能的情况下避免启用不必要的协议功能。组织还应清点每一个接收 SAML 断言的身份提供商、服务提供商、自定义连接器和遗留集成，然后核实它们各自如何处理签名和解析器边界情况。迁移项目应保留这些控制措施，而不应把更换协议视为安全配置的替代品。
对于新的 Web 集成，OIDC 可能是一种合理的替代方案，尤其是在其授权码流程和后端通道通信符合系统架构的情况下。然而，现有证据既没有证明它同样支持每一种 SAML 部署模式，也没有确立一条普遍适用的迁移路径。采用身份提供商发起式流程、基于隔离网络假设，或具有特殊企业需求的团队，需要明确测试兼容性。过渡期间可能有必要同时支持两种协议，但每增加一种受支持的协议，都会带来额外的配置与验证工作。
更广泛的启示是，身份验证协议会随着其规范与实现一同老化。SAML 能够长期存在，反映了它确实具有互操作性和部署价值；但这并不意味着它的复杂性没有危害。反过来，发现 XML 与签名处理反复出现失败，也不能支持“每一次 SAML 登录都不安全”的说法。安全团队应将 SAML 视为一项承载风险的依赖，减少不必要的灵活性，及时更新库，并要求提供证据，证明实际部署的完整流程已经针对已知的解析器和签名攻击接受过测试。