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

大家好，这里是架构资源栈！点击上方关注，添加“星标”，一起学习大厂前沿架构！

从一开始，Logto 就坚信开放标准。我们选择遵循OIDC、OAuth 2.0和SAML等协议——不仅因为它们被广泛使用，更因为它们代表了业界值得信赖的成熟安全实践。安全始终是我们的首要任务。我们始终秉持开源精神，并遵循客户身份管理和现代身份验证的最佳实践。

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

OAuth 2.0 和 OIDC 对每个人来说都并非易事。对于不熟悉这些协议的开发者来说，这些概念可能会让他们感到陌生，有时甚至违反直觉。这给我们带来了真正的挑战，因为我们致力于在不损害安全性的情况下简化开发者体验。

有两件事引人注目：

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

这是我们的 Discord 用户经常问的一个问题（为了保护隐私，他们的 ID 和头像都被混淆了）。

每个决策都伴随着权衡——但有时，随着新用例的出现，你早期做出的选择会显得尤为重要。我们现在正在进入一个新时代：人工智能时代。

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

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：“这是用户，他们现在已登录。”

OIDC 通过添加用户身份验证和身份数据扩展了 OAuth 2.0，同时保持与其核心授权框架完全兼容。

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. 他们安全登录

   → 这是 MFA、生物识别或社交登录等功能发生的地方。

3. Logto 将他们送回

   → 附带安全令牌或授权码。

4. 您的应用完成登录

   → 令牌已验证，用户已登录。

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

• 您的应用程序不会直接处理凭证 - 这意味着更少的风险。
• 无需更改应用程序代码即可更轻松地添加 MFA 等功能。
• 它也适用于移动设备：
  • iOS 使用ASWebAuthenticationSession
  • Android 使用自定义标签

如果您的产品跨越多个应用程序，重定向允许单点登录- 用户只需登录一次，即可在应用程序之间顺畅移动。

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. 您有交互需求：您不仅仅是对用户进行身份验证——您还在创建一个生态系统，外部应用程序、合作伙伴或代理可以与您的平台集成并安全地访问用户数据。

为什么 OAuth 和 OIDC 在人工智能时代比以往任何时候都更重要

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

1. 远程 MCP 服务器

   您构建了一个远程 MCP（模型上下文协议）服务器，并希望第三方代理能够连接到该服务器。这些代理需要安全的访问权限才能请求上下文、执行操作并交换数据，而这一切都不能损害用户的信任。OAuth 提供了安全授权访问权限的机制。

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

   您运营着自己的业务服务（例如项目管理工具或客户平台），并希望让其他产品或代理与其集成。这可能意味着提取数据、触发工作流或将您的功能嵌入到其他环境中。OAuth 2.0/OIDC 支持基于令牌的细粒度访问控制，无需共享用户凭证。

3. 建立自己的代理

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

4. 智能设备的兴起

   得益于 LLM，AI 翻译器或智能会议笔记器等硬件设备的功能日益强大。随着成本降低和性能提升，越来越多的此类设备正在涌入市场。这些设备通常需要一种方式来验证用户身份并访问基于云的服务——尤其是在输入接口有限的情况下。这时，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。

也就是说，如果您计划扩展、提供集成或构建 AI/代理驱动的工作流，OIDC 和 OAuth 2.0 是早期明智的投资。它们可以节省后期时间，并避免围绕授权和访问控制的技术债务。

关于选择正确的身份验证策略的最终想法

您可能不需要立即使用 OAuth 2.0 或 OIDC——这完全没问题。在早期阶段，简单的解决方案通常就能满足需求。但随着产品的发展，随着代理和人工智能越来越融入我们的构建方式，以及随着您的生态系统向合作伙伴和第三方开放，安全且标准化的身份验证将不再是可有可无的，而成为必需品。

与其日后追赶，不如现在就打好基础。采用 OAuth 2.0 和 OIDC 不仅是为了解决当前的问题，更是为了为未来的发展做好准备。

如果这篇文章对你有帮助的话，别忘了【在看】【点赞】支持下哦~

原文地址：https://mp.weixin.qq.com/s/aoro2rjxZnbh4S2PVg-ZUw
本文由博客一文多发平台 OpenWrite 发布！