SAML：坏设计的分形
SAML 这一广泛用于企业的基于 XML 的单点登录标准，正越来越多地被批评为过度复杂、不安全，而且是委员会式设计的产物，难以正确实现。评论者将其与 OAuth2/OpenID Connect 和 JWT 对比，认为后者更简单、更安全，但也并非完美，且同样受到各自生态与商业激励（如“SSO 税”）的影响。许多人认为，SAML 之所以持续存在，是因为企业惯性和遗留 IdP；但新产品在可能的情况下应优先选择 OIDC，并把 SAML 当作需要逐步淘汰的遗留技术。
企业需求 vs 供应商选择
- 许多人认为，企业产品必须支持客户所使用的任何 SSO（通常是 SAML）；否则它们根本没有生存空间。
- 也有人反驳说，供应商没有义务采用他们认为不安全的协议；失去这类客户是商业决策，不是义务。
- 一些供应商表示，他们转为仅支持 OIDC 后，实际上大多数“SAML 客户”都能顺利切换，因为他们的 IdP 本来就支持 OIDC。
- 经济角度：SAML 功能常被放在付费墙后（“SSO 税”），供应商会收取数千美元来“打开开关”，理由是支持和维护成本。
SAML vs OIDC/OAuth2/JWT
- 普遍共识是，SAML 比 OAuth2/OIDC 和 JWT 更复杂、更脆弱，尽管 OAuth2/OIDC/JWT 也并非没有非平凡的坑。
- 关于“OAuth2 很烂”的争论，焦点在于它是否被误用作认证而不是授权；OIDC 被视为合适的认证层。
- 有人认为，由于企业惯性，SAML 可能会比 OIDC 存活更久；也有人主张把 SAML 当作过时遗留技术（例如 IE6）逐步淘汰。
安全与实现陷阱
- SAML 的 XML 签名是讨论重点：签名可以覆盖由攻击者选择的子集，依赖规范化，并且容易受到 XML Signature Wrapping 攻击。
- 许多实现历史上只是验证了“某个”签名，然后就信任整个文档，或者错误使用 XML-sig 库（例如使用攻击者提供的密钥进行 HMAC、WebPKI 验证）。
- 讨论中提到的 JWT/JOSE 问题包括：
alg:none、算法混淆、对称与非对称密钥混用。不过，许多参与者认为 JWT 的问题更少，也更容易缓解，相比之下 SAML 更糟。
IdP 发起 vs SP 发起流程
- 有人为 SAML 辩护，认为它适合 IdP 发起的 SSO，以及“安全内置于载荷中”的设计，尤其是在企业门户场景下。
- 也有人指出，IdP 发起流程容易受到登录 CSRF 影响；OIDC 刻意避免这类流程，而是使用第三方发起流程，但仍然从 SP 开始。
- 对于用户确认提示是否能有效缓解此类攻击，存在分歧。
XML、复杂性，以及委员会式设计
- 多条评论将 SAML 的问题归因于 XML 和委员会式设计：签名/加密选项太多，规范规模也极其庞大。
- 有人将其与 OSI vs IP、OpenVPN vs WireGuard、XML vs JSON 相比较，作为更简单、更有主见的设计通常表现更好的例子。
联合身份、“SSO 税”与替代方案
- 原始 OpenID、OpenID Connect 的动态发现/注册、IndieAuth，以及 DID/FedCM 被提为与平台无关身份的构建模块。
- 线程中的共识是：阻碍广泛联合登录的主要是商业激励（数据囤积、SSO 加价），而不是缺少技术。
- 有人认为，实际工作中，SCIM 的不一致如今比 SAML vs OIDC 的协议问题更耗费精力。