【问题标题】：OAuth 2.0 In Microservices: When a resource server communicates with another resource server微服务中的 OAuth 2.0：当一个资源服务器与另一个资源服务器通信时
【发布时间】：2019-02-16 19:56:03
【问题描述】：
目前，用户正在将带有 [Scope A] 的访问令牌传递给 Web 门户。
一旦用户请求查看资源，令牌就会被传递到资源服务器 [Web App A] 以获取资源。但是，要获取资源，资源服务器必须与[Web App B]通信以获取信息子集，因此需要[Scope B]。由于用户仅授权 [Scope A]，因此调用将失败。
以下是可以应用的修复方案：
- 场景一：请求用户授权[Scope A]和[Scope B]。这里的问题是用户可能不希望 [Web Portal] 直接访问 [Web App B]。
- 场景 2：[Web App A] 成为 [Web App B] 的客户端，使用自己的访问令牌向 [Web App B] 请求资源。这里的问题是用户上下文丢失了。
我正在寻找标准解决方案，我可能做错了什么。
还有几个问题我想问：
- 是否应该在微服务中传递访问令牌？
- 内部请求是否应该有不同的授权框架？
【问题讨论】：
标签：
api
oauth
oauth-2.0
authorization
microservices
【解决方案1】：
如果这些是不同的应用程序（对用户而言），那么是的，应该要求用户确认他是否愿意授权 A 访问 B。如果他不想这样做，那么 A 没有业务与 B 交谈代表上述用户。
如果这是一组微服务，那么用户需要通过网页进行交互，并且如果对 n 个不同的服务进行任何后续调用是用户不应该关心的事情。因此，他信任网页并要求网页提供一些数据。你有一套微服务来回答这个问题，用户和他的令牌不关心。
所以你可以使用第二个选项。谈论用户上下文，可以以其他形式共享，例如通过标头传递。
是否应该在微服务中传递访问令牌？
是的，那应该没有害处。它增加了有效载荷，但肯定可以做到。需要注意的重要一点是，服务可以使用用户访问令牌来模拟用户对另一个服务的调用。如果此类调用对您的设计构成威胁，那么您应该重新考虑。但大多数情况下，我们认为您在边界内所做的任何事情都是安全的，您可以信任该边界内的其他服务，因此可以将其传递。
内部请求是否应该有不同的授权框架？
这取决于，如果您出于安全原因想要将其分开，则可以，如果您出于负载原因想要将其分开，则可以。
您还可以考虑在网关处剥离令牌（在入口点验证令牌）并释放它。对于您可以信任其他服务（在您的微服务中）并确保除了 API 网关之外没有人可以直接访问它们的系统，您可以放开令牌。
您放松了授权位，但我们的重点是我们信任服务并相信他们知道自己在做什么，因此我们不会对此类调用施加限制。