面向微服务体系结构的OAuth 2.0流
我正在努力了解如何最好地将OAuth 2.0授权类型应用到我正在研究的微服务体系结构中。这是情况..。
我有一个单页应用程序/移动应用程序，作为一个客户端运行在一个网络浏览器(浏览器充当用户代理)或移动电话。我使用在中定义的隐式格兰特( RFC 6749，第4.1节 )对用户进行身份验证，并获取该应用程序用于访问一些外部公开的API的访问令牌。
我正在处理的架构是一组相互调用的微服务。例如，考虑外部公开的API serviceA和内部API serviceB和serviceC。假设serviceA依赖于serviceB，它随后依赖于serviceC (A -> B --> C)。
我的问题是，在这种情况下，典型的授权流程是什么？是否标准使用SPA隐式授权来获取访问令牌，然后使用客户端凭据授予RFC 6749，第4.4节中定义的访问令牌以获取访问令牌，以便机器能够在serviceB和serviceC之间进行交互。
回答 3
Stack Overflow用户
发布于 2018-02-28 08:14:03
对于单个页面应用程序，使用隐式授予，它是为浏览器应用程序设计的--它们不能保存任何机密，并且使用隐式授予时，令牌留在浏览器中(因为它位于重定向URL的散列部分)。
移动应用程序，看看适用于本地应用程序的OAuth 2.0，它推荐使用Auth代码授权。它还描述了通用平台的实现细节和安全性考虑。
OAuth 2.0令牌交换RFC中描述了一种新的授权，可以满足您对服务之间链接调用的需求：
..。例如，OAuth资源服务器可能在令牌交换期间充当客户端的角色，以便将它在受保护的资源请求中接收的访问令牌交换为适合包含在对后端服务的调用中的新令牌。新令牌可能是对下游服务范围更窄的访问令牌，也可能是完全不同类型的令牌。
但我不知道Auth0是否支持它。如果没有，我可能会将原始访问令牌从serviceA传递给serviceB和serviceC。内部服务也可以在网络级别上得到保护(例如，它们只可以从其他服务调用)。
Stack Overflow用户
发布于 2018-02-27 22:34:18
如果serviceB和serviceC是内部的，并且永远不会从外部客户端调用，那么客户机凭据授予将是一个很好的候选。因为客户端也是一个资源服务器。
您还可以考虑在服务之间传递相同的承载令牌，前提是SPA (最初请求令牌)获得其他服务可能使用的所有范围的同意，并且令牌的“受众”必须允许所有可能的资源服务器(服务)。
我不认为这两种方法都是最佳实践，两者都有取舍。
Stack Overflow用户
发布于 2018-02-27 19:50:27
我真诚地建议每个后端服务实现授权授权。即有一个端点将重定向暴露到您的提供程序。然后，对于每个前端应用程序，转到该端点以触发OAuth流。流完成后，处理回调url中的授权部分，并返回一个令牌，该令牌将存储在前端某处。
希望这能有所帮助。
https://stackoverflow.com/questions/49013500
复制相似问题
腾讯云开发者
