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