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

Posted 2021-04-08

当前，用户将访问令牌与[范围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]请求资源。这里的问题是用户上下文丢失了。

我正在寻找标准的解决方案，我可能会在最后做错事。

我想问一些其他问题：

• 访问令牌是否应该绕微服务传递？
• 内部请求是否应该有不同的授权框架？

答案

如果这些是不同的应用程序（对用户）然后是，则应该要求用户确认他是否愿意授权A访问B.如果他不想这样做，那么A没有商业代表B代表用户说。

如果这是一组微服务，则用户需要通过Web页面进行交互，如果对不同的服务进行任何后续调用，则用户不应该关注这些内容。因此，他信任网页并向网页询问一些数据。你有一套微服务坐在后面回答这个问题，不关心用户和他的令牌。

所以你可以使用第二个选项。谈论用户上下文，可以通过标题传递等其他形式共享。

访问令牌是否应该绕微服务传递？

是的，那应该没有坏处。它增加了有效载荷，但肯定可以做到。需要注意的重要一点是，服务可以使用用户访问令牌来模仿用户对另一个服务的调用。如果此类电话对您的设计构成威胁，那么您应该重新考虑。但大多数情况下，我们觉得你在你的边界内所做的事情是安全的，你可以信任该边界内的其他服务，因此可以传递它。

内部请求是否应该有不同的授权框架？

这取决于，如果你想出于安全原因将它分开，你可以，如果你想按负载原因这样做，你可以。

您还可以考虑在网关处剥离令牌（在入口点验证令牌）并放弃它。对于您可以信任其他服务（在您的微服务中）并且确保没有人可以直接访问它们的系统，除了API网关之外，您可以让令牌进入。你失去了授权位，但我们的另一点是我们信任服务并相信他们知道他们在做什么，所以我们不对这些电话施加限制。