OAuth2流程理解

Question

我试图了解如何保护我的应用程序。 我选择使用 Auth0 来管理我的用户和应用程序。

我见过这样的流程：

我试图理解这个流程，但我错过了一些东西。 假设我有一个 Web 应用程序，一个 API 网关，它试图调用一个内部应用程序，它是资源服务器。

据我从图片流中了解到：

1. API 网关应用通过 Auth0 进行身份验证，并获取访问令牌。

2. API 网关应用使用访问令牌调用资源服务器。

现在我错过了一些东西，不应该有另一个箭头，从资源服务器到 Auth0，带有访问令牌，来验证它还是什么？

另一个问题，检查我是否理解，如果我想对用户进行身份验证： 1.用户使用Auth0登录，获取token。

1. 用户使用令牌调用API网关。

2. API 网关使用 Auth0 验证令牌。

3. API 网关调用资源服务器

4. 资源服务器正在使用 Auth0 验证令牌？

谢谢:)

Answer 1

一般来说，API 网关处理身份验证，然后通过在适用时向内部服务器执行附加请求来重定向/处理请求。这里的前提是，由于某种类型的网络约束，内部服务器只能通过 API 网关访问，因此不必对经过身份验证的身份进行任何额外的验证——它们信任网关传递的身份，并假设任何必要的验证都已执行。

在这种情况下，API 网关是接收和验证令牌的资源服务器，它通过发出额外的内部请求来履行职责这一事实是一个实现细节。

此外，令牌的验证可以通过两种方式之一完成，只有一种方式意味着资源服务器和授权服务器之间的通信：

• 通过额外调用令牌的颁发者来验证令牌，并根据其响应执行任何决定。
• 验证资源服务器本身的令牌；实现这一点的最常见方法是使用可以在令牌本身中包含信息的令牌格式（想想JSON Web Token），并让授权服务器（Auth0）以资源服务器可以验证的方式对该令牌进行签名签名并确信令牌内容由授权服务器提供且未被篡改。

如前所述，这是最常见的设置，并假设 API 网关之后的任何下游服务器都不会公开，因此不需要执行身份验证决策 - 也就是令牌验证。这些下游服务器可能仍需要用户身份才能做出额外的授权决策，但它们可以通过与令牌不同的方式接收此信息并隐式信任接收到的信息。

---

如果您的下游服务器也可以直接从不受信任的网络访问，则这种方法将不起作用，但如果是这种情况，您可能还需要考虑通过部署 API 网关可以获得什么好处。