OAuth2流程理解

Question

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

我看过这个流程：

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

据我从图像流程中了解：

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

2. API网关应用程序使用访问令牌对资源服务器进行评估。

现在我想念一些东西，从资源服务器到使用访问令牌的Auth0，是否有一个更好的箭头来验证它或什么？

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

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

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

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

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

谢谢：）

Answer 1

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

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

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

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

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

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