解密SAML和OAuth：现代身份验证的开启钥匙

认证和授权是确保应用程序和数据安全访问的关键支柱。无论是规模大小还是行业，每个组织都优先考虑保护用户身份并控制对敏感资源访问的强大机制。多年来，这些流程经历了重大演变，从传统做法转向现代、标准化协议，如SAML和OAuth。几十年前，认证依赖于每个服务或应用程序的单独用户名和密码组合。虽然这种方法可行，但它带来了许多挑战，包括糟糕的用户体验、可扩展性问题以及凭证盗窃或网络钓鱼等安全风险的增加。今天我们将详细了解一下SAML和OAuth。

SAML（安全断言标记语言） 应运而生作为一种解决方案。通过实现 单点登录（SSO），SAML 允许用户只需一次认证即可访问多个应用程序和服务，无需重复输入凭证。这通过身份提供者集中认证用户的身份，从而为用户和服务提供商提供了无缝和安全的体验。

例如，使用 SAML，员工可以使用组织的单点登录(Single Sign-On, SSO)门户进行一次登录，然后访问电子邮件、项目管理平台和文件共享服务等类似的工具，而无需重复登录。这不仅可以提高工作效率，同时保持强有力的安全保障。

传统的登录方式是怎样的，

• 用户为其访问的每个应用程序输入用户名和密码。
• 每个应用程序负责自己的登录验证并保存用户登录信息。

未启用单点登录

现在来说说传统登录方式的挑战。

• 同时管理多个应用程序的多个凭证的用户。
• 增加了遭受网络钓鱼或凭证盗窃等攻击的风险。
• 频繁登录各种应用程序。

SSO 登录时，它是如何工作的：

通过单点登录（SSO），您可以只需登录到公司登录门户这样的中央系统。系统会检查您的凭证并确认您的身份。通过验证后，您可以访问多个应用和服务，无需重新登录，因为它们信任中央系统来验证。

使用单点登录 (SSO)

• 用户通过身份提供者（IdP）进行单次身份验证，即可访问多个应用程序。这被称为单点登录。
• 应用程序依赖一个受信任的身份提供者来验证用户身份。
• 凭证不会重复传递给各个应用程序。

• 身份提供方（IdP）： 验证用户身份并提供身份声明（例如：Google、Okta、Active Directory、Azure AD）。
• 服务提供方（SP）： 依赖身份提供方来验证身份（例如：Credly、GitHub、YouTube）。
• 声明： 身份提供方分享的包含身份验证信息的数据包。
• SAML请求/响应： 服务提供方与身份提供方之间的通信，用于发起和完成身份验证过程。

• 用户通过身份验证提供者（如其组织的单点登录门户）或比如说通过他们的 Google 账户登录。
• Facebook 将用户重定向到 IdP（如 Google），用户在那里进行身份验证。
• 用户在 Google 安全登录页面上输入其凭证。Google 验证凭证并确认用户身份信息。
• 验证成功后，Google IdP 生成 SAML 断言（Security Assertion Markup Language 断言），这是一个包含用户身份和其他属性的安全数据包。
• SAML 断言发送给服务提供者（如 Facebook）。
• Facebook 验证 SAML，确保其来自受信任的 IdP，如 Google。
• 最后，用户可以直接访问他们的 Facebook 账户，无需额外凭证。

要用 SAML 登录 Facebook 和 YouTube 哦

这个无缝的流程保障了使用一套凭证在各个服务中安全高效地登录认证。

OAuth ，全称开放授权，是一种广泛使用的协议，旨在允许在不共享密码的情况下安全访问资源。重要的是要理解 OAuth 不是一种身份验证机制——它不会确认你是谁。相反，OAuth 侧重于你被允许做什么，因此它是一种 授权机制。身份验证 的意思是“你是谁？”它通常通过登录过程确认你的身份，而不是通过 OAuth。另一方面，授权 意味着“你被允许做什么？”它控制你可以对服务执行哪些操作。

比如，当你用App上传照片到Instagram时。OAuth允许该应用程序代你发布内容，而无需你提供Instagram的用户名和密码。相反，应用程序只获取一个有限的令牌，该令牌授予执行此特定任务的权限令牌。

OAuth 不涉及验证你的身份。它假设你已经通过其他方式完成了身份验证，并专注于访问资源或权限（例如查看文件或发布内容）。

为什么我们要用OAuth而不是SAML？

• SAML设计用于身份验证（验证身份）。
• OAuth设计用于授权（授予权限）。
• OAuth更适合在不同应用程序间授予用户数据的有限访问权限。

• 许多服务需要在不共享密码的前提下，精细地访问用户的个人资料。
• 例如: 将 YouTube 视频发布到 LinkedIn。

场景: 某个用户将他们的动态分享到他们的 LinkedIn 个人资料。

授权步骤：

• 使用单点登录，通过 Google 账户登录 YouTube。
• YouTube 会将用户重定向到 LinkedIn 的 OAuth 授权页面。
• 用户允许 YouTube 在其 LinkedIn 账户上发布内容。
• LinkedIn 提供一个临时令牌给 YouTube 使用。
• YouTube 使用该令牌代表用户发布内容，无需提供 LinkedIn 账户凭证。

• 资源所有者: 数据的所有者（例如 LinkedIn 账号）。不要将访问 YouTube 和 LinkedIn 的用户与他们在 LinkedIn 上的身份混淆，因为同一个用户也会通过 LinkedIn 进行身份验证。因此，SAML 和 OAuth 有时会同时工作。
• 客户端: 请求访问的应用程序（例如 YouTube）。YouTube 作为客户端，请求访问用户 LinkedIn 账号的权限。
• 授权服务器: 确认用户同意并颁发令牌（例如 LinkedIn 的 OAuth 服务器）。它验证用户的身份，并确保用户同意让 YouTube 访问他们的 LinkedIn 资源（如发布更新）。
• 访问令牌: 一个临时令牌，允许客户端访问特定的资源。它允许客户端代表用户执行特定的操作。用户同意后，LinkedIn 会向 YouTube 发放一个 访问令牌。YouTube 使用此令牌直接将用户的视频或内容发布到 LinkedIn 上，而无需用户输入 LinkedIn 密码。
• 范围: 定义允许的访问权限（例如发布到 LinkedIn 与读取用户数据）。它们确保客户端只能执行用户明确同意的操作。

在使用OAuth 2.0时，理解这些术语非常重要。让我们通过一个例子来尝试理解它们。想象一下地铁交通系统。上车流程通常如下：乘客向自动售票机或售票员处请求票/令牌。售票员或机器发放有效时间或站数有限的令牌/票。然后，乘客用令牌通过入口闸门；如果令牌有效，闸门就会自动开启，乘客就可以顺利乘车了。

OAuth 可以比作地铁站

乘客（客户端）想乘坐地铁（受保护的资源），因此向售票员（授权服务器）请求票。售票员代表地铁管理部门（资源所有者）发放票/令牌（令牌）。

OAuth 就像 地铁站的闸机，确保你安全地进入和使用服务。

OAuth ，即开放授权，是一种广泛使用的协议，旨在允许在不分享密码的情况下安全访问资源。需要注意的是，OAuth 并不是一个身份验证机制——它不会验证你的身份。相反，它专注于你被允许做什么，因此，它更像是一种授权机制。

比如说，你用一个应用把照片发到 Instagram。OAuth 让应用可以在不使用你的 Instagram 账户名和密码的情况下替你发布内容。相反，应用会获得一个仅限用于特定任务的令牌。

• 认证 回答：“你到底是谁？”它通过登录来确认你是谁。
• 授权 回答：“你被赋予了哪些权限？”它控制你可以做什么，或一个应用可以在服务上执行哪些操作。

OAuth 不处理身份验证，而是假设你已经通过其他方式完成身份验证，并专注于资源访问或权限，比如查看文件或发布内容。

SAML vs. OAuth: 对比分析

为了填补认证空白，OAuth 有一个配套协议叫做 OIDC。OIDC 在 OAuth 的基础上构建，不仅提供用户认证，还提供授权。

• OAuth：允许应用程序代表用户访问资源。
• OIDC：添加用户认证，让应用程序验证用户身份并获取信息，比如姓名或电子邮件。

OAuth 和 OIDC 不仅提供了安全的授权，还提供了无缝的认证。例如：一个 GitLab CI/CD 流水线作业在不存储如服务账户密钥等敏感信息的情况下，将应用部署到 GCP。这是通过使用 OIDC 进行认证和 OAuth 2.0 进行授权来实现的。

OAuth 已经有相当长的历史了。安全就像一场猫捉老鼠的游戏。首先设计并实现一个协议，接着黑客发现并利用这些漏洞，导致协议需要修补来应对这些问题。

由于 OAuth 协议非常通用，它变得既复杂又抽象。因此，很容易误解这些文档。这种情况可能导致严重的后果。如果没有深入的理解和对细节的关注，很容易以一种不安全的方式实现它。阅读一份关于常见 OAuth 漏洞的列表：常见 OAuth 漏洞列表。

这就是为什么不要自己实现一个OAuth服务器哦，自己实现OAuth服务器是很危险的。

• 使用身份提供商作为服务。（例如 Identity Server、Auth0 和 Azure Active Directory 等。）
• 或者下载并修改一个符合 OpenID Connect 标准的实现：here。

另外，仔细选择哪种资助形式适用于您的情况。仔细考虑被破解的可能性以及可能的影响。

虽然 SAML 革新了用户认证，但现代应用程序需要的不仅仅是单一登录功能。OAuth 提供 安全的令牌授权 ，允许应用程序无需共享密码即可访问用户在其他平台上的资源。OAuth 并不负责验证您的身份。它假设您已通过其他方式完成身份验证，并专注于提供资源或权限的访问。

感谢阅读!!! 希望您觉得内容既有见地又实用。觉得有用的话，不妨分享一下，并关注我们的博客以获取更多更新。一起学习吧!