SAML vs OAuth：关键差异与最佳用例

入门指南：一个有帮助的类比

SAML 和 OAuth 的核心区别在于它们所使用令牌（tokens）的性质。SAML 会交给你一枚很大、看起来很“官方”的 XML 令牌。它被盖章、做了公证，闻起来都像是文件材料。相对而言，OAuth 则会给你一枚很小的 JWT 令牌，并说：“给你，这个可以让你进 VIP 区待上几个小时。只要别弄丢就行。”

有一个很方便的方式来形象化理解这种差异。SAML 就像去参加一场只对特定人开放的派对——你会怀疑自己到底能不能被允许进入。幸好，你的朋友会在门口出面，说：“这个人跟我在一起；他/她很不错。”于是主办方不问任何问题就让你进去了，而且你可以待多久都行。

OAuth 更像是有人把他们的车借给你。对方不会让你访问他们的房子、银行账户或自行车——只借给你那辆车而已。类似地，OAuth 会在不泄露你所有信息的情况下，授权你执行特定的事情。你可能在点击“使用 Facebook 登录”或“使用 Google 登录”时就见过这种方式。Facebook 或 Google 会把完成任务所需的足够信息提供给你想访问的应用——例如你的姓名和电子邮箱地址——但不会提供你整个人生的全部故事。特别是，OAuth 不会把你的密码与应用共享。相反，它会提供一个专门的 Web 令牌（web token），用来说明：“这个人被允许做 X、Y 和 Z。”

深入探究：SAML（Security Assertion Markup Language）

我们说过，SAML 就像是朋友为你作担保，让你进入派对。使用 SAML 时，你请求的不是“进入派对”的权限，而是对某个应用或服务的访问权限；而那个朋友就是身份提供方（identity provider，例如 Google 或你公司内部的系统）。它会告诉该服务：它已经对你完成了身份验证，所以服务应该批准你的访问请求。

主要使用场景

SAML 的主要优势在于实现单点登录（SSO）——让用户只需完成一次身份验证，即可访问多个系统，而无需再次登录或使用单独的账号。

因此，SAML 非常适合 SSO 至关重要的环境，例如教育、医疗和政府等行业的企业。如果你需要在不同域中的多个应用之间管理用户，并希望在不迫使用户多次登录的情况下简化身份验证，那么 SAML 就是首选协议。

SAML 的工作原理

SAML 包含三个主要组件：

• 用户 — 试图获得访问权限的人
• 服务提供商 — 用户希望访问的应用或服务的承载方
• 身份提供方 — 对用户进行身份验证的实体

这些组件的交互方式如下：

1. 用户尝试访问某个应用或服务。
2. 服务提供商将用户重定向到身份提供商以进行身份认证。
3. 身份提供商会检查用户是否已完成身份认证（如未认证，则执行认证步骤），并返回一份用于证明用户身份的 XML 令牌。
4. 服务提供商根据 XML 令牌为用户授予访问应用程序或服务的权限。

SAML 的关键特性

• 联合身份 — 允许在不同域之间共享身份
• SSO — 实现不同系统之间无缝身份验证
• 企业应用 — 主要用于 B2B 场景，在这种环境下，确保在内部与第三方应用之间安全共享身份至关重要
• 基于 XML — 在各方之间的通信中高度依赖 XML

使用 SAML 的优势

• 降低账户被入侵的风险 — 由于用户只需要一组凭据，他们更可能选择强密码，并且无需采用诸如把密码写下来这类高风险的变通方式也能记住密码。
• 降低 IT 运维负担 — 与登录问题相关的密码重置和支持工单更少，节省了用户和 IT 人员的时间。
• 降低密码被盗风险 — 密码不会在用户和服务提供方之间传输。

深入解析：OAuth

我们说 OAuth 就像一个朋友：允许你使用他的汽车，但不把他的其他任何物品交给你。类似地，OAuth 会在不共享你的密码的情况下，授权一组有限的访问权限。例如，OAuth 使你能够授权第三方应用或网站访问你的 Facebook 照片——而不会暴露 Facebook 针对你存储的其他任何信息，包括你的登录凭据。

OAuth 如何工作

OAuth 的主要组成部分包括：

• 客户端 — 代表用户请求访问某个资源的应用程序
• 资源所有者 — 拥有被请求的数据或应用的用户或系统，并可授予对其的访问权限
• 授权服务器 — 在用户同意之后签发令牌（token）的服务器
• 资源服务器 — 存储该资源的 API 或服务

流程如下：

1. 用户希望向客户端应用程序授予对其相关特定数据的访问权限，而这些数据由资源所有者持有。
2. 客户端向相应的授权服务器发起授权请求。
3. 授权服务器对客户端进行身份验证，从资源所有者处获得访问同意，并向客户端发送访问令牌。
4. 客户端使用访问令牌，向资源服务器请求对所需资源的访问。

OAuth 的使用场景

OAuth 最适用于面向消费者的应用，以及当第三方应用需要对用户数据进行有限访问的场景。例如，如果你正在构建一款需要从外部 API 获取数据的移动应用，OAuth 提供了一种安全且标准化的方式，用于授予该访问权限，而无需损害用户的凭据。

OAuth 的关键特性

• 侧重于授权 —— 旨在在不共享凭据的情况下授予第三方对资源的访问权限
• 以 API 为中心 —— 广泛用于保障对 API 的访问安全，尤其是在移动端、Web 和云应用中
• 基于令牌 —使用访问令牌（通常为 JSON 格式）来允许或拒绝访问
• 面向消费者 — 常用于 Facebook 和 Google 等 B2C 应用。

使用 OAuth 的优势

• 降低数据泄露风险 — OAuth 使用令牌，只能在有限时间内访问特定资源。
• 灵活性 — OAuth 可用于移动设备、桌面端、Web 浏览器以及物联网设备。
• 提升客户满意度 — 组织可以使用 Google 或 Facebook 等可信的第三方授权系统，让用户访问其自身资源，从而简化客户体验。

对比分析：SAML vs. OAuth

SAML 和 OAuth 的相似之处

• OAuth 和 SAML 都支持单点登录（Single Sign-On），使用户只需完成一次身份验证即可访问多个服务。
• 这两种协议都能够在多个系统、应用程序或组织之间共享身份信息。
• 这两种协议都通过消除与第三方服务共享或存储凭据的需求，提升了用户便利性和安全性。

SAML 与 OAuth 的区别

• OAuth 使用轻量级的基于 JSON 的令牌，而 SAML 使用冗长的基于 XML 的令牌。
• OAuth 通常用于面向消费者的 Web 和移动应用，而 SAML 主要用于企业级 SSO 和身份联合。
• OAuth 令牌用于授权对 API 的访问，而 SAML 断言用于在系统之间建立认证。

并排对比

协议共存

在需要同时进行身份验证和授权的系统中，SAML 和 OAuth 可以协同工作。例如，员工可能使用 SAML 登录企业系统，但随后系统会颁发 OAuth 访问令牌，使其能够与 Microsoft Graph 或 Google Drive 等外部服务或 API 进行交互。

安全隐患与最佳实践

令牌窃取与重放攻击

由于 OAuth 令牌通常有效期较长，因此容易被恶意行为者截获。攻击者可以使用这些令牌访问关键数据或系统。例如，OAuth 令牌可能会通过诸如中间人（Man-in-the-Middle）攻击等技术被拦截，或从未得到充分保护的存储中被窃取。

为降低这些风险，组织可以使用有效期较短的访问令牌，并始终使用 HTTPS（它提供 TLS 加密）。

XML Signature Wrapping

XML 签名是附加在 XML 文档上的数字签名，例如附加在 SAML 令牌上。有效的签名表明该文档来自受信任的来源，且未被篡改。攻击者可以通过在保持有效签名的同时向 SAML 令牌注入恶意数据来利用这种验证机制。

为防御这些攻击，组织可以要求使用强数字签名，并对 SAML 令牌进行加密，以保护其完整性和机密性。

未来趋势与发展

各组织正在迅速摒弃仅依赖传统密码的身份验证方式，转而采用诸如多因素认证（multifactor authentication，MFA）以及类似 passkeys 这类“无密码”选项。更广泛地说，他们正在引入 Zero Trust 安全模型，该模型强调“永不信任，始终验证”的必要性。此外，他们还借助人工智能（AI）和机器学习（ML）来增强威胁检测能力。

结论

尽管 SAML 和 OAuth 都在管理对应用程序和数据的访问方面发挥至关重要的作用，但它们着眼于不同的挑战：SAML 侧重于确认用户身份，通常用于企业环境中的单点登录（SSO）；而 OAuth 则面向更细粒度、无密码的授权设计，使 Web 和移动应用程序能够安全访问 API 和资源。两种协议都将支持你在保持强安全性的同时，打造更顺畅、更简单的用户体验。