当我完全信任依赖方时，为啥我应该遵循 Oauth2.0 和 OpenID Connect Protocole 而不是仅使用 JWT 的基本身份验证？

Posted 2023-03-07

【中文标题】当我完全信任依赖方时，为啥我应该遵循 Oauth2.0 和 OpenID Connect Protocole 而不是仅使用 JWT 的基本身份验证？

【英文标题】：Why should I follow Oauth2.0 and OpenID Connect Protocole instead of basic authentication with just a JWT when I fully trust the relying party?当我完全信任依赖方时，为什么我应该遵循 Oauth2.0 和 OpenID Connect Protocole 而不是仅使用 JWT 的基本身份验证？

【发布时间】：2021-06-03 16:20:30

【问题描述】：

我目前正在开发一个第一次使用微服务的项目。这是我想出的架构：

一个 Laravel Web 应用服务器 Api 网关 身份验证服务器 受保护的微服务

首先我考虑使用 Oauth 2.0 和 OpenID Connect 协议，其中 Laravel Web 应用服务器是 Oauth 2.0 客户端（OpenID Connect 依赖方），受保护的微服务是资源服务器。

Oauth 2.0 用于授权对受保护资源的访问，使用访问令牌（和可选的刷新令牌），OpenID Connect 是建立在 Oauth2 之上的身份验证协议，以便为第三方客户端提供对基本用户的访问权限数据（通过用户端点）并允许他们验证用户身份，并且它使用包含有关用户的声明的 ID 令牌，不像访问令牌没有任何有关用户的信息。

---

对于客户端是第三方应用程序的情况，这是清楚易懂的，但是当客户端是第一方应用程序时，例如我正在开发的 Laravel Web 应用程序，我对我如何应接近认证程序。我有两个选择，如果我有什么误解，请告诉我。

选项 1：实施资源所有者密码授予流程（遵循 Oauth 2.0 和 OpenID Connect）

我可以使用这个流程，因为客户端（Laravel 服务器）不是第三方应用程序，并且可以信任用户凭据，所以基本上，流程如下所示：

用户输入邮箱和密码，从 Laravel 服务器通过 API 网关发送到 Auth 服务器。 Auth Server 返回一个 Access Token 和一个 ID Token。 当用户尝试访问受保护资源服务器（微服务 1、2 和 3）中的可用资源时，请求从 Laravel 客户端发送到 API 网关，然后在发送到微服务之前，API 网关将请求转发到 Auth 服务器以验证令牌。 如果有效，则将请求发送到目标微服务，带有ID Token，微服务可以识别用户。

选项 2：仅使用一个 JWT 令牌。

这对我来说似乎更容易，并且比使用资源所有者流程实现 OpenID Protocole 和 Oauth 2.0 更有意义。

用户尝试登录，请求被发送到身份验证服务器。 Auth Server 返回一个包含用户信息的 JWT Token。 然后请求直接通过 API 网关发送到微服务。

---

也许我误解了一些东西，但如果我不是，并且这两个选项都是可能的，我的问题是，如果您信任 OpenID Connect 依赖方（Oauth 2.0 客户端）和用户凭证，为什么还要遵循资源所有者密码凭证流程。为什么不直接为它提供一个包含用户信息的令牌而不是访问令牌和 id 令牌？也许这是一种更安全的方法？

我期待一些澄清。

【参考方案1】：

遵循标准可为您带来一些优势。首先，您的安全性被破坏的可能性较小，因为在创建标准时考虑了一些常见的攻击媒介。其次，如果您使用标准在您的服务之间进行通信，那么您将来交换系统的任何元素都会容易得多。如果在某些时候，您认为您创建的 Auth Server 不够用，并且您想将其与市场上的产品进行交换，那么如果您使用 OAuth 和 OpenID，这将很容易。如果您使用自己提出的协议，您将很难更改服务器。

另一件事是对您的服务有明确的关注范围。如果我理解正确，在第二种方法中，它将是执行身份验证的 Web 服务器，而身份验证服务器只会发出令牌，对吗？如果 Auth 服务器也将执行身份验证，那么它与使用 ROPC 几乎相同 - 唯一的区别可能是参数的名称。但如果是前一种情况，那么您就会开始混淆关注点——Web 服务器负责身份验证，这可能会使将来的事情变得复杂。

如果您正在构建一个您知道不会扩展的小型系统，那么使用 ROPC 就足够了（出于安全原因，遵循标准仍然很好）。如果您认为系统可能会随着时间变得更大，那么将关注点分开并遵循标准很重要，否则您最终会得到一个无法维护且不安全的系统。

查看有关 Neo security 和 security maturity models 的这些资源，您可以在其中阅读有关如何构建现代安全平台的更多信息。

【讨论】：

感谢您的回答。对于第二种方法，实际上是 Auth 服务器将执行身份验证。该方法与 ROPC 流程几乎相同，但我担心的是协议本身，因为在我看来，不需要不包含可在受保护资源中使用的用户信息的访问令牌，那么为什么不坚持使用 ID Token 作为访问令牌呢，这是第二种解决方案。而且据我了解，放弃访问令牌意味着协议不能再称为Oauth2.0和OpenID Connect

我会说你会反过来 - 只使用访问令牌并在其中放入可以识别用户的附加声明。这样，您可以坚持使用 OAuth，但保留 OpenID 连接部分。

非常感谢您的帮助