为什么你的产品需要 OAuth 2.0 和 OIDC——特别是在 AI 时代

从一开始，Logto 就是基于对开放标准的坚定信念而构建的。我们选择遵循 OIDC、OAuth 2.0 和 SAML 等协议，不仅因为它们被广泛使用，更是因为它们代表了行业公认的、安全的实践。安全一直是我们的首要任务。我们也始终忠实于开源精神，遵循 客户身份管理 和现代身份验证的最佳实践。

但在此过程中，我们也学到了一些东西：

OAuth 2.0 和 OIDC 对于很多人来说并不容易。对于不熟悉这些协议的开发者而言，这些概念可能会显得生疏甚至反直觉。这导致了我们在不妥协安全性的情况下如何简化开发者体验方面面临真正的挑战。

两个方面尤为突出：

1. 即使我们努力使集成尽可能顺畅，围绕理解 ID 令牌、访问令牌及其工作原理的基本概念仍存在学习曲线。
2. 我们经常被问到的一个问题是：“我可以跳过登录屏幕上的重定向吗？”不幸的是，重定向是 OIDC 工作方式的核心部分，是实现安全身份验证所必需的。

我们 Discord 用户常见的问题（隐去其 ID 和头像以保护隐私）。

每个决策都有权衡取舍，但有时你早期做出的选择在新的用例出现时显得尤其有价值。而我们正进入一个新时代：AI 时代。

在本文中，我将探讨何时你的产品应该使用 OIDC 和 OAuth 2.0，何时可能不需要它们，以及为什么我一直主张从一开始就采用这些开放标准，尤其是当你在建立一个真实的业务并选择 CIAM 解决方案时。我还将解释为什么 AI 的兴起使这一决策比以往任何时候都更为重要。

OAuth 2.0 的真正作用（用一个简单的比喻来说明）#

对于不太熟悉 OAuth 2.0 的读者，我将花些时间简单介绍一些基本概念，以便更清楚地说明。

OAuth 2.0 用于委托授权：OAuth 2.0 是一个行业标准的授权协议——它允许一个服务在资源所有者同意的情况下代表其访问另一个服务的资源。

在 OAuth 场景中，用户（资源所有者）将有限访问（访问权限）授予客户端应用程序，以访问 API 或资源服务器，而无需分享他们的密码。OAuth 定义了如何请求和发布访问令牌以便客户端可以调用受保护的 API。这与早期应用可能要求你提供凭据来访问另一个服务（这是一个严重的安全风险）的日子相比，是一个变革性的。借助 OAuth 2.0，用户批准特定访问，而客户端获取了仅包含所需权限和期限的令牌——无需交换密码，从而显著提高安全性。

可以将 OAuth 2.0 想象成入住酒店的过程。

你（用户）是房间（数据）的拥有者。但与其把房间钥匙（密码）交给他人，不如去前台请求一张临时门卡（访问令牌），该门卡仅允许你的客人或朋友进入健身房或泳池，而非整个房间。

酒店工作人员（OAuth 系统）发布了这张有特定规则的有限卡：

• 它仅适用于健身房（特定资源）。
• 它在短时间内有效。
• 它不允许任何人进入你的房间。

通过这种方式，你不必交出主钥匙——即使有人拿到了那张有限卡，系统仍然安全。

我们再来看另一个例子。OAuth 2.0 广泛用于社交登录场景。

假设你正在注册一个新的应用程序，如 Notion，而不是创建新的用户名和密码，你点击 “继续使用 Google”。

以下是 OAuth 2.0 的幕后工作原理：

1. 你被重定向到 Google 的登录页面，在那里登录（如果还未登录）。

2. Google 询问：

   “你允许此应用查看你的基本资料和电子邮件地址吗？”

3. 你点击“允许”，然后 Google 向应用发送一个访问令牌。

4. 应用使用该 令牌 来：

   • 确认你的 身份（通过你的电子邮件和个人信息）。
   • 创建或让你登录账户——而不需要查看你的 Google 密码。

OIDC 的真正作用（用一个简单的比喻来说明）#

现在让我们来看看 OIDC——一个更新且更高级的标准。OpenID Connect 旨在实现身份和身份验证：它是构建在 OAuth 2.0 之上的 身份验证 层。虽然 OAuth 2.0 本身并不告诉应用程序用户是谁（仅涉及访问令牌和范围），但 OIDC 增加了一种标准化方式来处理用户登录和身份。

在使用 OIDC 时，授权服务器也充当 OpenID 提供者（一个身份提供者），它验证用户并发布一个包含用户信息的 ID 令牌（即“身份声明”）。

简而言之，OAuth 2.0 回答了 “该客户端能否访问该资源？” 和 OIDC 回答了 “刚刚登录的用户是谁？”。它们结合起来，允许你的应用验证用户的身份，然后使用授权的令牌代表用户访问 API。

让我们用酒店比喻来更好地理解 OAuth 2.0 和 OIDC。

想象你正在酒店登记入住。

• OAuth 2.0 就像请求酒店让你的 朋友 使用健身房和泳池。

  你前往前台，授予权限，酒店给你的朋友一张 客用通行证。

  酒店不关心该朋友 是谁——仅仅是他们可以使用设施。

  👉 那就是 OAuth： “这个应用可以访问我的一些数据或服务。”

• OIDC 就像请求酒店在让他们进入前检查 该人是谁。

  所以你的朋友还出示了一张 身份证——酒店现在知道他们的名字、身份，并且他们是经过验证的客人。

  👉 那就是 OIDC： “这个用户是谁，他们现在已登录。”

Logto 如何使用 OAuth 2.0 和 OpenID Connect (OIDC)#

Logto 的核心身份验证功能构建在 OIDC (OpenID Connect) 之上#

从其核心来看，Logto 是一个 OpenID Connect (OIDC) 提供者——一个构建在 OAuth 2.0 之上的标准，专注于安全、现代的用户身份验证。Logto 是一个专业的 CIAM 解决方案，身份是我们管理的核心构建模块。

我们以安全为基础设计 Logto。这意味着默认启用 PKCE，阻止不安全的流程如 隐式流程，并依赖 重定向 安全处理登录。

为什么需要重定向？#

OIDC 旨在用于基于浏览器的身份验证。这不仅是技术选择——这是关于为用户提供跨平台的安全、一致体验。重定向用户到身份提供者（如 Logto、Google 或 Microsoft）有助于实现这一目标。

以下是 典型流程 的样子：

1. 用户点击“登录”

   → 你的应用程序将他们发送到 Logto 的登录页面。

2. 他们安全登录

   → 这就是多因素验证、生物识别或社交登录发生的地方。

3. Logto 将他们发回

   → 连同一个安全令牌或授权码。

4. 你的应用完成登录

   → 验证令牌，用户登录成功。

这种模式看似简单，但带来了强大的好处：

• 你的应用程序不直接处理凭证——这意味着更少的风险。
• 更容易添加诸如多因素验证这样的功能，而无需更改应用代码。
• 在移动端也表现良好：
  • iOS 使用 ASWebAuthenticationSession
  • Android 使用 Custom Tabs

如果你的产品跨多个应用，重定向允许 单点登录——用户只需一次登录，即可无缝切换应用。

Logto 不支持在应用中直接收集密码。这是有意为之。ROPC 流程 并不推荐用于 OAuth 2.0 的安全最佳实践，原因很好认为——它不太安全且难以安全扩展。

Logto 也是一个 OAuth 2.0/OIDC 提供者（身份提供者）#

Logto 不仅仅是一个身份验证服务器——它还是一个完整的 OAuth 2.0、OpenID Connect (OIDC) 和身份提供者 (IdP)。这意味着它可以安全地管理用户身份并发布其他应用可信任的令牌。

除了为你自己的应用提供登录体验之外，Logto 还支持 第三方应用集成，允许外部服务依赖 Logto 作为它们的身份来源。

这在实践中意味着什么？

作为一个 身份提供者 (IdP)，Logto 处理用户验证、管理凭证并发布身份验证令牌。一旦用户登录，Logto 可以让他们访问不同的应用——甚至是其他供应商的应用——而无需再次登录。这就像“使用 Google 登录”或“使用 Microsoft 登录”的背后概念。

在此上下文中有两类应用程序：

• 第一方应用：你构建和完全控制的应用，直接与 Logto 集成。
• 第三方应用：由你的组织外的合作伙伴或开发者构建的外部服务。

Logto 使你的用户能够使用现有的 Logto 帐户登录这些第三方应用程序——就像企业用户使用 Google Workspace 凭证登录 Slack 等工具一样。这允许你：

• 在你的生态系统中提供 单点登录 (SSO)。
• 构建一个 开放平台，第三方开发人员可以将“使用 Logto 登录”添加到他们的应用中。

你什么时候真正需要 OAuth 2.0 和 OIDC？#

1. 如果你之前使用过 Auth0（或类似应用）: Auth0 已经是一个 OAuth 2.0 和 OIDC 提供者。它管理用户登录、令牌发布，并与你的 API 或应用集成。
2. M2M 授权：服务器到服务器（客户端凭证流） 机器（或后端服务）需要在没有用户的情况下进行安全通信。
3. 设备流：智能电视、游戏机、物联网设备： 诸如电视或打印机等设备需要验证用户。设备流是 OIDC 的一部分。
4. 你有交互需求：你不只是验证用户——你正在创建一个生态系统，外部应用、合作伙伴或代理 可以与您的平台集成并安全访问用户数据。

为什么在 AI 时代 OAuth 和 OIDC 比以往更加重要#

在 AI 时代，我们看到新的集成和访问需求激增——尤其是在自主代理、智能设备和系统到系统通信领域。这些趋势使 OAuth 2.0 和 OIDC 比以往更加重要。以下是一些示例：

1. 远程 MCP 服务器

   你构建了一个远程 MCP（模型上下文协议）服务器，并希望第三方代理连接到它。这些代理需要安全访问来请求上下文、执行操作以及交换数据——所有这些都不会损害用户信任。OAuth 提供了一种机制来安全地委托访问。

2. 开放你的产品以进行集成

   你经营自己的业务服务——比如项目管理工具或客户平台——你希望让其他产品或代理与其集成。这可能意味着提取数据、触发工作流或将功能嵌入其他环境。OAuth 2.0/OIDC 实现无需共享用户凭证的细粒度令牌访问控制。

3. 构建你自己的代理

   你在创建一个 AI 代理或助手，并希望它能与其他应用和 MCP 服务器交互——安排会议、发送电子邮件、发布更新或查询数据。这些需要安全的、经过身份验证的访问第三方服务。OAuth 2.0 是你的代理获得代表用户执行操作的授权方式。

4. 智能设备的兴起

   如 AI 翻译器或智能会议记录器这样的硬件设备得益于 LLM 变得更加强大。而随着成本降低和性能提高，越来越多的此类设备涌入市场。这些设备通常需要一种方法来验证用户并访问基于云的服务——尤其是当输入接口有限时。流如 OAuth 的 设备授权流 和基于 OIDC 的身份验证对于这种情况变得至关重要。

你可能不需要 OAuth 2.0/OIDC 的时候#

当然，也有你可能不需要 OAuth 2.0 或 OIDC 的情况——至少现在不需要。换句话说，如果你当前的用例简单或完全自包含，这些协议可能不会带来直接的价值。

然而，随着你的产品发展或你的生态系统扩展，长期来看对 OAuth 2.0 和 OIDC 的需求往往会更加明显。

1. 简单的内部应用

   如果你的应用仅供公司内部小团队使用，并且不需要与第三方服务集成或暴露 API，一个基本的用户名密码身份验证系统（例如，cookie 会话）可能已经足够。

2. 不需要用户身份验证

   如果你的产品没有用户账户或身份感知功能——比如公共内容网站或具有静态 API 密钥的服务器到服务器工具——OIDC 是不需要的。

3. 不需要委托访问

   当你需要用户授权应用访问其在另一个系统中的数据（例如，Google Drive）时，OAuth 才显示出其优势。如果你不集成第三方 API 或构建多服务工作流，OAuth 增加的复杂性带来的价值有限。

4. 单一环境，风险极少

   对于早期阶段的原型、MVP 或内部测试工具，当简单性和速度超越安全性需求时，你可以选择推迟实施 OAuth/OIDC。

关于选择正确的身份验证策略的最终思考#

你可能不需要立即使用 OAuth 2.0 或 OIDC——这完全没问题。在初期阶段，简单的解决方案往往就能完成任务。但随着你的产品成长，代理和 AI 越来越深地融入我们构建的方式，以及你的生态系统向合作伙伴和第三方开放，安全和标准化的身份验证不再是一个可有可无的，而是一个必须。

与其以后再追赶，不如现在就打下基础。采用 OAuth 2.0 和 OIDC 不仅仅是为了解决当今的问题——也是为了准备好应对未来的变化。