当我完全信任依赖方时，为什么我应该遵循 Oauth2.0 和 OpenID Connect Protocol 而不是仅使用 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?
我目前正在从事一个第一次使用微服务的项目。这是我想出的架构：
- 一个Laravel Web 应用程序服务器
- 一个Api网关
- 认证服务器
- 受保护的微服务
首先我考虑使用 Oauth 2.0 和 OpenID Connect 协议，Laravel Web 应用服务器是 Oauth 2.0 客户端（OpenID Connect 依赖方），受保护的微服务是资源服务器。
Oauth 2.0 用于授权访问受保护的资源，使用访问令牌（和可选的刷新令牌），OpenID Connect 是建立在 Oauth2 之上的身份验证协议，以便为第三方客户端提供访问权限基本用户数据（通过用户端点）并允许他们验证用户身份，它使用 ID Tokens，其中包含关于用户的声明，不像没有关于用户的任何信息的访问令牌。
对于客户端是第三方应用程序的情况，这是清楚易懂的，但是当客户端是第一方应用程序时，例如我正在开发的 Laravel Web 应用程序，我是对于我应该如何处理身份验证程序有点困惑。我有两个选择，所以如果我误解了什么请告诉我。
选项 1：实施资源所有者密码授予流程（遵循 Oauth 2.0 和 OpenID Connect）
我可以使用此流程，因为客户端（Laravel 服务器）不是第三方应用程序并且可以信任用户凭据，所以基本上，流程如下所示：
- 用户输入他的电子邮件和密码，这些电子邮件和密码从 Laravel 服务器通过 API 网关发送到 Auth 服务器。
- Auth 服务器returns 一个访问令牌和一个 ID 令牌。
- 当用户尝试访问受保护资源服务器（微服务 1、2 和 3）中可用的资源时，请求从 Laravel 客户端发送到 API 网关并在之前它被发送到微服务，API 网关将请求转发到 Auth 服务器以验证令牌。
- 如果有效，则将请求发送到目标微服务，带有ID Token，微服务可以识别用户。
选项 2：仅使用一个 JWT 令牌。
这个对我来说似乎更容易，并且比使用资源所有者流程实施 OpenID Protocol 和 Oauth 2.0 更有意义。
用户尝试登录，请求被发送到Auth Server。
Auth Server returns 一个包含用户信息的 JWT Token。
然后请求直接通过 API 网关发送到微服务。
也许我误解了什么，但如果我没有误解，并且这两个选项都是可能的，我的问题是，如果您信任用户的 OpenID Connect 依赖方（Oauth 2.0 客户端），为什么还要费心遵循资源所有者密码凭证流程证书。为什么不只为它提供一个包含用户信息的令牌而不是访问令牌和 ID 令牌呢？也许这是一种更安全的方法？
我期待一些澄清。
遵循标准会给您带来一些优势。首先，您的安全性不太可能遭到破坏，因为这些标准是在考虑了一些常见的攻击媒介的情况下创建的。其次，如果您使用标准在您的服务之间进行通信，那么您将来交换系统的任何元素都会容易得多。如果，在某个时候，您应该决定您创建的 Auth Server 是不够的，并且您想用市场上的产品交换它，如果您使用 OAuth 和 OpenID，这将很容易。如果您使用自己想出的协议，您将很难更改服务器。
另一件事是对您的服务有明确的关注点。如果我理解正确的话，在第二种方法中，将由 Web 服务器执行身份验证，而 Auth 服务器只会颁发令牌，对吗？如果 Auth 服务器也将执行身份验证，那么它与使用 ROPC 几乎相同 - 唯一的区别可能是参数名称。但如果是前一种情况，那么您就会开始担心 - Web 服务器负责身份验证，这可能会使将来的事情复杂化。
如果您正在构建一个您知道不会扩展的小型系统，那么使用 ROPC 就足够了（出于安全原因，遵循标准仍然很好）。如果您认为系统可能会随着时间的推移变得更大，那么将关注点分开并遵循标准很重要，否则您最终会得到一个无法维护和不安全的系统。
查看有关 Neo security and security maturity models 的这些资源，您可以在其中详细了解如何构建现代安全平台。
我目前正在从事一个第一次使用微服务的项目。这是我想出的架构：
- 一个Laravel Web 应用程序服务器
- 一个Api网关
- 认证服务器
- 受保护的微服务
首先我考虑使用 Oauth 2.0 和 OpenID Connect 协议，Laravel Web 应用服务器是 Oauth 2.0 客户端（OpenID Connect 依赖方），受保护的微服务是资源服务器。
Oauth 2.0 用于授权访问受保护的资源，使用访问令牌（和可选的刷新令牌），OpenID Connect 是建立在 Oauth2 之上的身份验证协议，以便为第三方客户端提供访问权限基本用户数据（通过用户端点）并允许他们验证用户身份，它使用 ID Tokens，其中包含关于用户的声明，不像没有关于用户的任何信息的访问令牌。
对于客户端是第三方应用程序的情况，这是清楚易懂的，但是当客户端是第一方应用程序时，例如我正在开发的 Laravel Web 应用程序，我是对于我应该如何处理身份验证程序有点困惑。我有两个选择，所以如果我误解了什么请告诉我。
选项 1：实施资源所有者密码授予流程（遵循 Oauth 2.0 和 OpenID Connect）
我可以使用此流程，因为客户端（Laravel 服务器）不是第三方应用程序并且可以信任用户凭据，所以基本上，流程如下所示：
- 用户输入他的电子邮件和密码，这些电子邮件和密码从 Laravel 服务器通过 API 网关发送到 Auth 服务器。
- Auth 服务器returns 一个访问令牌和一个 ID 令牌。
- 当用户尝试访问受保护资源服务器（微服务 1、2 和 3）中可用的资源时，请求从 Laravel 客户端发送到 API 网关并在之前它被发送到微服务，API 网关将请求转发到 Auth 服务器以验证令牌。
- 如果有效，则将请求发送到目标微服务，带有ID Token，微服务可以识别用户。
选项 2：仅使用一个 JWT 令牌。
这个对我来说似乎更容易，并且比使用资源所有者流程实施 OpenID Protocol 和 Oauth 2.0 更有意义。
用户尝试登录，请求被发送到Auth Server。 Auth Server returns 一个包含用户信息的 JWT Token。 然后请求直接通过 API 网关发送到微服务。
也许我误解了什么，但如果我没有误解，并且这两个选项都是可能的，我的问题是，如果您信任用户的 OpenID Connect 依赖方（Oauth 2.0 客户端），为什么还要费心遵循资源所有者密码凭证流程证书。为什么不只为它提供一个包含用户信息的令牌而不是访问令牌和 ID 令牌呢？也许这是一种更安全的方法？
我期待一些澄清。
遵循标准会给您带来一些优势。首先，您的安全性不太可能遭到破坏，因为这些标准是在考虑了一些常见的攻击媒介的情况下创建的。其次，如果您使用标准在您的服务之间进行通信，那么您将来交换系统的任何元素都会容易得多。如果，在某个时候，您应该决定您创建的 Auth Server 是不够的，并且您想用市场上的产品交换它，如果您使用 OAuth 和 OpenID，这将很容易。如果您使用自己想出的协议，您将很难更改服务器。
另一件事是对您的服务有明确的关注点。如果我理解正确的话，在第二种方法中，将由 Web 服务器执行身份验证，而 Auth 服务器只会颁发令牌，对吗？如果 Auth 服务器也将执行身份验证，那么它与使用 ROPC 几乎相同 - 唯一的区别可能是参数名称。但如果是前一种情况，那么您就会开始担心 - Web 服务器负责身份验证，这可能会使将来的事情复杂化。
如果您正在构建一个您知道不会扩展的小型系统，那么使用 ROPC 就足够了（出于安全原因，遵循标准仍然很好）。如果您认为系统可能会随着时间的推移变得更大，那么将关注点分开并遵循标准很重要，否则您最终会得到一个无法维护和不安全的系统。
查看有关 Neo security and security maturity models 的这些资源，您可以在其中详细了解如何构建现代安全平台。