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

如何解决当我完全信任依赖方时，为什么要遵循 Oauth2.0 和 OpenID Connect Protocole 而不是仅使用 JWT 的基本身份验证？

我目前正在处理一个首次使用微服务的项目。这是我想出的架构：

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

首先我考虑使用 Oauth 2.0 和 OpenID Connect 协议，Laravel Web App Server 是 Oauth 2.0 客户端（OpenID Connect Relying Party），受保护的微服务是资源服务器。

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

对于客户端是第三方应用程序的情况，这很清楚并且可以理解，但是当客户端是第一方应用程序时，例如我正在开发的 Laravel Web 应用程序，我有点困惑我如何应该接近认证程序。我有两个选择，所以如果我误解了什么，请告诉我。

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

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

用户输入他的电子邮件和密码，这些信息从 Laravel 服务器通过 API 网关发送到 Auth 服务器。
身份验证服务器返回访问令牌和 ID 令牌。
当用户尝试访问受保护资源服务器（微服务 1、2 和 3）中可用的资源时，请求会从 Laravel 客户端发送到 API 网关，然后再发送到微服务 API 网关将请求转发到身份验证服务器以验证令牌。
如果有效，则将请求发送到目标微服务，带有ID Token，微服务可以识别用户。

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

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

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

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

我期待一些澄清。

解决方法

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

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

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

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