在一篇文章中理解 IAM、OAuth、OpenID Connect、SAML、SSO 和 JWT

身份和访问管理（IAM）领域近年来变得更加复杂。诸如 OAuth、OpenID Connect (OIDC)、SAML、SSO 和 JWT 之类的术语经常被使用，但它们意味着什么？它们如何协同工作？让我们探索这些概念和框架，使它们变得更易理解和实用。

什么是 IAM？#

身份和访问管理（IAM）是一个广泛的概念，涉及管理数字身份和实施访问控制。前面提到的框架和协议属于 IAM，每个都解决该领域的特定挑战。

本质上，IAM 是关于：

• 身份：用户、服务或设备的数字表示。身份通常包含名称、电子邮件、角色等属性，以描述实体。
• 访问：与资源互动、执行操作或使用服务的能力。访问定义了可以在哪些资源上执行哪些操作。

在上面的图中，用户（身份）希望在 API（资源）上执行 GET 请求。用户的属性 - 名称、电子邮件和角色 - 描述了身份。

认证 vs. 授权#

认证和授权经常同时出现在 IAM 讨论中。让我们明确它们的定义：

• 认证：验证身份所有权的过程。它回答了“你拥有什么身份？”这个问题。
• 授权：确定经过身份验证的身份可以对资源执行哪些操作的过程。它回答了“你能做什么？”这个问题。

在之前的例子中：

• 在用户（身份）可以执行任何操作之前，他们必须完成认证过程。
• 认证完成后，系统需要确定用户是否可以在 API（资源）上执行 GET 请求（操作），即完成授权过程。

---

拥有这些基础知识后，让我们来解开其他缩写和协议的神秘面纱。

OAuth#

OAuth 2.0，通常称为 OAuth，是一个授权框架，允许一个应用程序访问另一个应用程序上的受保护资源（通常代表用户）。

例如，假设你有一个名为 MyApp 的 Web 应用程序，想要访问用户的 Google Drive。与其要求用户共享他们的 Google Drive 凭据，MyApp 可以使用 OAuth 2.0 来请求 Google 的许可（授权）以访问用户的 Drive。

以下是 OAuth 流程的简化图示：

在此流程中：

• MyApp 是请求访问 Google Drive（资源）的客户端（身份）。
• 用户（资源所有者）在步骤 6 授予 MyApp 权限，完成授权过程。

OAuth 2.0 的一个关键元素是访问令牌，客户端使用它来展示用户访问资源的授权。深入了解，请参阅 Access token。

OpenID Connect (OIDC)#

OpenID Connect (OIDC) 是建立在 OAuth 2.0 之上的认证层。它添加了专门用于认证的功能，例如 ID 令牌和 UserInfo 端点，使其适用于认证和授权。

如果我们重温 OAuth 流程，添加 OIDC 会引入一个 ID 令牌。此令牌包含有关已认证用户的信息，并使 MyApp 能够验证用户的身份。

例子场景：“使用 Google 登录”#

让我们换个例子。如果 MyApp 想要允许用户使用他们的 Google 帐户登录，目标就转向认证而不是资源访问。在这种情况下，OIDC 更加适合。以下是 OIDC 流程的样子：

关键区别：除了访问令牌，OIDC 提供了一个 ID 令牌，这使得 MyApp 能够在不需要额外请求的情况下认证用户。

OIDC 共享 OAuth 2.0 的 grant 定义，确保两个框架之间的兼容性和一致性。

SAML#

安全断言标记语言 (SAML) 是一个基于 XML 的框架，用于在各方之间交换认证和授权数据。SAML 于 2000 年代初引入，被广泛应用于企业环境。

SAML 如何与 OIDC 比较？#

SAML 和 OIDC 在功能上相似，但在实现细节上有所不同：

• SAML：使用基于 XML 的断言，通常被认为更复杂。
• OIDC：利用 JSON 和 JWT，使其更轻便且更易于开发。

现代应用程序通常因其简单性和灵活性而偏好使用 OIDC，但 SAML 仍在遗留系统和企业用例中很普遍。

单点登录 (SSO)#

单点登录 (SSO) 是一种认证方案，使用户能够使用一套凭据访问多个应用程序和服务。用户无需单独登录每个应用程序，只需一次登录即可访问所有连接的系统。

SSO 如何工作？#

SSO 依赖于中心 身份提供者 (IdP) 来管理用户身份。IdP 验证用户并为连接的应用程序提供诸如认证和授权之类的服务。

IdP 可以使用 OIDC、OAuth 2.0、SAML 或其他协议提供这些服务。单个 IdP 可以支持多个协议，以满足不同应用程序的多样需求。

基于 OIDC 的 SSO 例子#

让我们来探讨一个基于 OIDC 的 SSO 例子：

在此流程中，用户登录到 IdP 一次，并在多个应用程序（AppA 和 AppB）上进行认证。

企业级 SSO#

尽管 SSO 是一个广泛的概念，你可能还会遇到企业级 SSO这个术语，它指专门为企业环境（通常为员工及合作伙伴）设计的 SSO。

当客户请求为你的应用程序使用 SSO 时，了解他们的需求和所使用的协议很重要。在大多数情况下，这意味着对于特定的电子邮件域，他们希望你的应用程序将用户重定向到他们的 IdP（实现了企业级 SSO）进行认证。

添加企业级 SSO 提供者的例子#

以下是将你的应用程序（MyApp）与企业级 SSO 提供者（Banana）集成的简化例子：

JWT#

JSON Web Token (JWT) 是在 RFC 7519 中定义的一个开放标准，支持两个方之间的安全通信。它是 OIDC 中 ID 令牌的标准格式，并广泛用于 OAuth 2.0 访问令牌。

JWT 的关键特性：

• 紧凑：JWT 是 JSON 对象，采用紧凑格式编码，便于传输和存储。
• 自包含：JWT 包含关于用户和令牌本身的所有必要信息。
• 可验证和可加密：JWT 可以被签名和加密，以确保数据的完整性和保密性。

典型的 JWT 看起来像这样：

这个 JWT 由由点隔开的三部分组成：

• Header：包含令牌的元数据，例如令牌类型和签名算法。
• Payload：包含关于身份和令牌本身的信息。
• Signature：验证令牌的完整性。

Header 和 Payload 都是 base64 编码的 JSON 对象。上面的 JWT 可以解码如下：

使用 JWT，客户端可以解码令牌并提取用户信息，而无需向身份提供者发出额外请求。要了解有关 JWT 的更多信息，请访问 JSON Web Token (JWT)。

回顾#

我们在这篇文章中涵盖了很多内容。让我们用一个例子来总结关键点：

假设你有一个需要**身份和访问管理（IAM）**解决方案的 Web 应用程序 AppA。你选择了 Logto，一个使用 OpenID Connect (OIDC) 进行认证的身份提供者。由于 OIDC 是建立在 OAuth 2.0 之上的，因此 Logto 还支持你的应用程序进行授权。

为了减少用户的摩擦，你在 Logto 中启用了“使用 Google 登录”。这使用 OAuth 2.0 交换授权数据和用户信息在 Logto 和 Google 之间。

用户通过 Logto 登录 AppA 后，AppA 接收到一个包含用户信息的 JSON Web Token (JWT) 类型的 ID 令牌。

随着业务的发展，你推出了一个新应用程序 AppB，也需要用户认证。由于 Logto 已经设置好，你可以重复使用相同的认证流程用于 AppB。你的用户现在可以通过一套凭据登录 AppA 和 AppB，这一功能称为单点登录 (SSO)。

后来，一个商务合作伙伴请求你连接他们使用 安全断言标记语言 (SAML) 的企业级 SSO 系统。你发现 Logto 支持 SAML 连接，因此你设置了 Logto 与合作伙伴 SSO 系统之间的连接。现在，合作伙伴组织的用户也可以使用他们现有的凭据登录 AppA 和 AppB。

---

希望这篇文章帮助你厘清这些概念。欲获取更深入的解释和例子，请访问 Auth Wiki。如果你正在为应用程序寻找 IAM 解决方案，考虑使用诸如 Logto 之类的托管服务可以节省时间和精力。