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