用于微服务架构的OAuth 2.0流程

Posted 2021-05-03

我正在尝试了解如何最好地将OAuth 2.0授权类型应用于我正在处理的微服务架构。这是情况......

我有一个单页面应用程序/移动应用程序充当在Web浏览器（充当用户代理的浏览器）或移动电话中运行的客户端。我使用RFC 6749, section 4.1中定义的隐式授权来验证用户并获取应用程序用来访问某些外部公开API的访问令牌。

我正在处理的架构是一组互相调用的微服务。例如，考虑外部公开的API serviceA和内部API serviceB和serviceC。让我们说serviceA依赖于serviceB，后来依赖于serviceC（A - > B - > C）。

我的问题是，这种情况的典型授权流程是什么？是否标准使用隐式授权为SPA获取访问令牌，然后使用RFC 6749, section 4.4中定义的客户端凭证授予获取机器的访问令牌以加工serviceB和serviceC之间的交互？

答案

对于单页应用程序，使用为浏览器应用程序设计的隐式授权 - 它们不能保留任何机密，并且使用隐式授权，令牌保留在浏览器中（因为它位于重定向URL的哈希部分中）。

移动应用程序，看看OAuth 2.0 for Native Apps，它建议使用Auth代码授予。它还描述了常见平台和安全注意事项的实现细节。

OAuth 2.0 Token Exchange RFC中描述了一个新的授权，可以满足您对服务之间链式呼叫的需求：

例如，OAuth资源服务器可能在令牌交换期间承担客户端的角色，以便交换在受保护资源请求中接收的访问令牌，以获取适合包含在呼叫中的新令牌到后端服务。新令牌可能是一个访问令牌，它对于下游服务的范围更窄，或者它可能是完全不同类型的令牌。

但我不知道Auth0是否支持它。如果没有，我可能会将原始访问令牌从serviceA传递给serviceB和serviceC。内部服务也可以在网络级别得到保护（例如，他们只能从其他服务中调用）。

另一答案

如果服务和服务是内部的，永远不会从外部客户端调用，那么客户端凭证授权将是一个很好的候选者。因为客户端也是资源服务器。

您还可以查看在服务之间传递相同的承载令牌，前提是SPA（最初请求令牌）获得其他服务可能使用的所有范围的同意，并且令牌的“受众”必须允许所有可能的资源服务器（服务）。

我认为这两种方法都不是最佳做法，而且两种方式都存在权衡。

另一答案

我诚实地建议每个后端服务实施授权授权。这是一个端点，将重定向暴露给您的提供者。然后，对于每个前端应用程序，转到该端点以触发OAuth流。完成流后，处理回调URL中的授权部分，并返回一个将存储在前端某处的令牌。

希望这可以帮助。