oauth-2.0 - 结合本机应用程序和后端进程的 OAuth 令牌的最佳实践

Question

我有一个场景，其中移动（本机）应用程序需要来自长时间运行的任务的数据。该任务代表用户持续运行，我们决定将其移至后端服务。要执行该任务，后端服务必须定期从受 OAuth2 保护的 API 获取数据。

我们的困境是我们不确定如何为后端服务提供一组访问令牌来访问数据 API。我们的移动应用程序使用带有 PKCS 的 OAuth2 授权授予流程来获取它自己的访问令牌、刷新令牌和 id-token（我们使用 OpenID Connect）。但是我们如何为我们的后端服务提供一组令牌呢？由于后端继续运行（也没有移动本机应用程序），我们希望为它提供自己的一组访问/刷新令牌。

似乎有几种解决方案：

• 通过后端代理所有移动应用程序与外部 API 的通信，使客户端成为私有客户端，使用授权代码流，并在本机应用程序和我们的后端之间设置自定义登录会话。对我来说，这意味着更多的运行后端基础设施，并实现会话管理，包括会话刷新等，这就像在我自己​​的服务器上重新实现 OpenId 流......
• 使用 OpenID 混合流，提供访问令牌和授权码以与后端共享。然而，这似乎是针对（浏览器内）网络应用程序，而不是原生移动应用程序，因为它基于隐式流程，因此安全性较低。
• 在移动应用程序上执行两次授权代码流（可选第二次，提示=无以禁止用户交互），为应用程序保留一个代码，将第二个代码转发到后端。然后后端和应用程序都可以用自己的代码交换访问令牌。这感觉有点像 hack，因为后端应该是私人客户端，而不是公共客户端。这是 Google 似乎在 CrossClientAuth 中宣传的方法
• 通过将 id-token 发送到后端来执行模拟，然后后端将该 id-token 交换为它自己的访问/刷新令牌集。微软在其“代表”场景中通过 jwt-bearer 授权来做到这一点。此外，令牌交换 RFC 似乎涵盖了相同的用例。但是，在这种情况下，id-token 被间接用作访问凭证，而不仅仅是作为关于用户身份的声明包，这在我看来很奇怪，因为访问应该通过访问令牌来控制，不是吗？此外，并非所有服务都应该被允许模拟，所以我认为这会带来额外的配置复杂性。

对我来说，我觉得我忽略了一些东西，这一定是其他人也遇到过的问题，而且之前必须已经解决了……在我的情况下，最好的做法是什么？

标签： oauth-2.0openidbackendmobile-application