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

Question

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

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

2. MicroBackend1 向 STS 执行 ActAs 令牌请求，然后将新的 JWT 传递给 MicroBackend2。这意味着用户上下文对于MicroBackend2是已知的。

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

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

Answer 1

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

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

如果将令牌从 UI 传递到下游，则利弊会有所不同。此外，为用户提供适当的角色也变得困难。

Answer 2

第三种方法可以完成工作并解决问题，而无需任何额外的努力。

不建议使用第二种方法，因为它会导致令牌服务的访问流量，从而增加响应时间。

但是，JWT 范围规则要求每个微服务创建自己的令牌，以便与任何其他微服务通信。这具有更安全的微服务和更高级别的跟踪的优点，但它带来了复杂的公钥基础设施的开销，以及在创建新 JWT 本身时的额外处理。

最后，您的安全要求和请求-响应 SLA 将决定哪种方法在它们之间保持平衡，并且最接近解决您的要求。