我正在尝试了解如何最好地将OAuth 2.0授权类型应用于我正在处理的微服务架构 . 这是情况......
我有一个单页面应用程序/移动应用程序充当在Web浏览器(充当用户代理的浏览器)或移动电话中运行的客户端 . 我使用RFC 6749, section 4.1中定义的 Implicit Grant 来验证用户并获取应用程序用来访问某些外部公开API的访问令牌 .
我正在处理的架构是一组互相调用的微服务 . 例如,考虑外部公开的API serviceA
和内部API serviceB
和 serviceC
. 假设 serviceA
取决于 serviceB
,后者依赖于 serviceC
( A
- > B
- > C
) .
我的问题是,这种情况的典型授权流程是什么?是否标准使用隐式授权为SPA获取访问令牌,然后使用RFC 6749, section 4.4中定义的 Client Credentials Grant 获取机器的访问令牌以加工 serviceB
和 serviceC
之间的交互?
3 回答
对于单页应用程序,使用为浏览器应用程序设计的隐式授权 - 它们不能保留任何机密,并且使用隐式授权,令牌保留在浏览器中(因为它位于重定向URL的哈希部分中) .
移动应用程序,看看OAuth 2.0 for Native Apps,它建议使用Auth代码授予 . 它还描述了常见平台和安全注意事项的实现细节 .
OAuth 2.0 Token Exchange RFC中描述了一个新的授权,可以满足您对服务之间的链接调用的需求:
例如,OAuth资源服务器可能在令牌交换期间承担客户端的角色,以便交换它在受保护资源请求中接收的访问令牌,以获取适合包含在打电话给后端服务 . 新令牌可能是一个访问令牌,它对于下游服务的范围更窄,或者它可能是完全不同类型的令牌 .
但我不会't know whether Auth0 supports it. If it doesn' t,我可能会将原始访问令牌从
serviceA
传递给serviceB
和serviceC
. 内部服务也可以在网络级别得到保护(例如,他们只能从其他服务中调用) .如果serviceB和serviceC是内部的,永远不会从外部客户端调用,那么客户端凭据授权将是一个很好的候选者 . 因为客户端也是资源服务器 .
您还可以查看在服务之间传递相同的承载令牌,前提是SPA(最初请求令牌)获得其他服务可能使用的所有范围的同意,并且令牌的“受众”必须允许所有可能的资源服务器(服务) .
我认为这两种方法都不是最佳做法,而且两种方式都存在权衡 .
我诚实地建议每个后端服务实施授权授权 . 这是一个 endpoints ,将重定向暴露给您的提供者 . 然后,对于每个前端应用程序,转到该 endpoints 以触发OAuth流 . 完成流后,处理回调URL中的授权部分,并返回一个将存储在前端某处的令牌 .
希望这可以帮助 .