mobile - 带有移动应用程序的混合流如何工作？

Question

我很难理解移动应用程序的混合流。我在 .Net 中使用 Identity Server 4 提供的代码 id_token 混合流。

这是我的场景。


所有移动请求都将转到后端服务器，后端服务器将代表用户将请求转发到不同的 API。

用户第一次登录时

他将被重定向到身份服务器

将打开移动 WebView

用户将使用凭据登录

身份服务器将向后端发送 ID token 和访问代码
服务器

后端服务器将交换 ID token 和访问 token 的访问代码

什么 token 将返回到移动应用程序以提供该用户是有效的。后端服务器是否有责任在用户注销之前获取新的访问 token 而不提示用户重新登录？

在上述情况下是否有任何步骤错误？

Answer 1

对于移动客户端，建议将授权代码流与 PKCE 一起使用。请通读这两个答案以了解为什么建议 Link-1 & Link-2 .
此外，RFC8252 为原生应用程序提供了一些最佳实践应用程序(移动客户端是原生应用程序。!)。在那，它建议不要使用 WebView 。
这里引用自 RFC8252-overview

Previously, it was common for native apps to use embedded user-agents(commonly implemented with web-views) for OAuth authorizationrequests. That approach has many drawbacks, including the host appbeing able to copy user credentials and cookies as well as the userneeding to authenticate from scratch in each app

通过使用 web View ，您将失去 OAuth 2.0 的真正本质。您的客户端应用程序能够获取最终用户凭据。所以使用浏览器而不是 WebView 。 (请从此 link 阅读有关嵌入式用户代理的更多信息)
在您的架构中，您可以启用所有这些、PKCE、授权代码流和使用浏览器而不是 Web View 。但是一旦被支持者收到 token ，它应该将它们传递给您的客户端。如果你坚持这种架构，那将是一个挑战。
但是如果你能让你的移动应用程序完成整个流程，你就避免了这种复杂性。收到 token 后，您可以通过验证 token 在支持的服务器之间创建连接。此外，当 token 过期时，移动应用程序将使用刷新 token 来获取新 token 。