假设我们在后端有很多微服务。有网关API服务授权用户执行在UI中完成的某些操作。比那个微服务（MicroBackend1）调用下一个微服务（MicroBackend2）而下一个调用下一个微服务（MicroBackend2）。什么JWT应该传递给MicroBackend1和MicroBackend2之间进行授权？哪种方法是正确的：
UI用户的JWT仅传递给第一个MicroBackend1。比它通过他自己的JWT到MicroBackend2。上下文知道在UI中执行操作的用户的上下文在MicroBackend2中不可用。 MicroBackend1对STS执行ActAs令牌请求，然后将新JWT传递给MicroBackend2。这意味着MicroBackend2已知用户上下文。 MicroBackend1直接将他从UI获得的JWT传递给MicroBackend2，因此它具有用户上下文。这些解决方案的优缺点是什么？您尝试过哪一个，我们应该选择哪一个？
投票
首先，我会说还有另一个选项，这是api网关本身的条带身份验证令牌，如果需要膨胀带有用户上下文的头，并将其传递给下游。我们倾向于这样做，因为我们考虑在api网关之后访问我们安全区域的一部分的任何服务。我们将所有防御措施放在api网关之前或之后。这允许服务自由地相互通信。但是我们这里也放弃了授权位。如果你可以忍受这种效果最好，因为它减少了一些开销，这是我最常使用的。
然而，在此之前，我曾经从UI获取JWT令牌，它由我们的节点层（BFF）验证，然后交换我们用来调用节点访问令牌的内容。基本上，我们在节点级别有一个用户，我们用它来生成此令牌并传递。这个令牌几乎所有东西都有授权（这种情况逐渐发生，最终我们最终放弃了对下游服务的授权）它帮助了我们，因为我们可以确保用户访问令牌对我们的下游服务几乎没用，如果调用了在下游直接使用用户令牌，它将被丢弃。生成我们自己的令牌的缺点是，我们最终提供了对这一个令牌的所有服务和所有api的访问权限。
如果您将令牌从UI传递到下游，则优点和缺点是相反的。同样给用户提供适当的角色变得困难。
投票
第三种方法可以完成工作并且无需任何额外的努力即可解决问题。
不建议采用第二种方法，因为它会导致对令牌服务的访问流量，从而增加响应时间。
然而，JWT范围规则要求每个微服务创建自己的令牌以与任何其他微服务进行通信。这具有更安全的微服务和更高级别的跟踪的优点，但它带来了复杂的公钥基础结构的开销以及创建新JWT本身的额外处理。
最后，您的安全要求和请求 - 响应SLA将决定哪种方法在它们之间保持平衡，并且最接近于满足您的要求。
