微服务中的OAuth 2.0：当资源服务器与另一台资源服务器通信时

Question

当前，用户正在将访问令牌和[范围A]传递给Web门户。 一旦用户请求查看资源，令牌就会传递到资源服务器[Web App A]以获取资源。但是，要获取资源，资源服务器必须与[Web App B]通信以获取信息的子集，因此它需要[范围B]。由于用户仅授权[作用域A]，因此呼叫将失败。

以下是可以应用的修复方案：

• 方案1：请用户授权[范围A]和[范围B]。这里的问题是用户可能不希望[Web Portal]直接访问[Web App B]。
• 场景2：[Web App A]成为[Web App B]的客户端，使用它自己的访问令牌从[Web App B]请求资源。这里的问题是用户上下文丢失。

我正在寻找标准解决方案，从一开始我可能做错了什么。

我想问的其他一些问题：

• 是否应该在微服务周围传递访问令牌？
• 内部请求是否应使用其他授权框架？

Answer 1

如果这些（对用户而言）是不同的应用程序，则是，应要求用户确认他是否愿意授权A访问B。如果他不想这样做，则A上没有与B交谈的业务代表该用户。

如果这是一组微服务，则用户需要通过Web网页与之交互，并且如果对n种不同的服务进行任何后续调用，则用户不必担心。这样，他就信任该网页并向网页询问一些数据。您后面有一组微服务来回答这个问题，用户和他的令牌无关紧要。

因此您可以使用第二个选项。谈论用户上下文，可以以其他形式共享，例如通过标头传递。

  

是否应该在微服务周围传递访问令牌？

是的，这应该没有伤害。它增加了有效载荷，但是可以做到。需要注意的重要一点是，服务可以使用用户访问令牌来模仿用户对另一个服务的调用。如果此类调用威胁到您的设计，则应重新考虑。但是大多数情况下，我们认为您在自己的边界内所做的一切都是安全的，并且您可以信任该边界内的其他服务，因此可以通过它。

  

内部请求是否应使用其他授权框架？

这取决于您是否出于安全原因将其分开，如果您出于负载原因而希望将其分开，则可以。

您还可以考虑在网关处剥离令牌（在入口点验证令牌）并放开它。对于您可以信任其他服务（在微服务中）并确保没有人可以直接访问它们的系统（API网关除外），您可以放开令牌。 您松开了授权位，但是我们要再次强调的是，我们信任服务并相信它们知道自己在做什么，因此我们不会对此类调用施加限制。