OAuth2流程理解

Question

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

我见过这个流程：

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

正如我从图像流中了解到的：

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

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

现在我错过了一些东西，难道不应该有另一个箭头，从资源服务器到 Auth0，使用访问令牌来验证它或其他什么？

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

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

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

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

5. 资源服务器使用 Auth0 验证令牌？

谢谢 ：）

Answer 1

通常，API 网关处理身份验证，然后通过执行（如果适用）对内部服务器的其他请求来重定向/处理请求。 这里的前提是，由于某种类型的网络限制，内部服务器只能通过 API 网关访问，因此不必对经过身份验证的身份执行任何额外的验证 - 他们信任网关传递的身份并假设任何必要的验证都已执行。

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

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

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

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

---

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