oauth - 使用 JWT 保护后端微服务之间的通信

Question

假设我们在后端有很多微服务。有网关 API 服务授权用户执行在 UI 中完成的某些操作。比那是微服务（MicroBackend1）调用下一个微服务（MicroBackend2），下一个调用下一​​个。MicroBackend1 和 MicroBackend2 之间应该传递什么 JWT 进行授权？哪种方法是正确的：

1. UI 用户的 JWT 仅传递给第一个 MicroBackend1。比它将他自己的 JWT 传递给 MicroBackend2。上下文知道在 UI 中执行的操作在 MicroBackend2 中不可用的用户上下文。

2. MicroBackend1 向 STS 发出 ActAs 令牌请求，然后将新的 JWT 传递给 MicroBackend2。这意味着 MicroBackend2 知道用户上下文。

3. MicroBackend1 直接将他从 UI 获得的 JWT 传递给 MicroBackend2，因此它具有用户上下文。

这种解决方案的优缺点是什么？您尝试过哪一种，我们应该选择哪一种？

标签： oauthoauth-2.0openidmicroservicesopenid-connect

Answer 1

首先，我会说还有另一个选项，这是在 api 网关本身中剥离身份验证令牌，如果需要使用用户上下文膨胀标头并将其传递给下游。我们倾向于这样做，因为我们会考虑您在通过 api 网关访问我们安全区域的一部分之后访问的任何服务。我们将所有防御措施放在 api 网关之前或处。这允许服务彼此自由交谈。然而，我们也在这里放松了授权位。如果你能忍受它，它会最有效，因为它减少了一些开销，这是我最常使用的。

然而，在此之前，我曾经从 UI 获取 JWT 令牌，它由我们的节点层 (BFF) 验证，然后交换我们过去称为节点访问令牌的东西。本质上，我们在节点级别有一个用户，我们曾经为该用户生成此令牌并传递。这个令牌对几乎所有东西都有授权（这逐渐发生，最终我们最终放弃了对下游服务的授权）它对我们很有帮助，因为我们可以确保用户访问令牌对我们的下游服务几乎没有用处，并且如果调用下游直接使用用户令牌将被丢弃。生成我们自己的令牌的缺点是我们最终授予了对所有服务和所有 API 的访问权限。

如果您将令牌从 UI 传递到下游，则利弊有些相反。给用户适当的角色也变得困难。