移动应用程序的混合流如何工作？答案

【问题标题】：How Hybrid flow with mobile application works?移动应用程序的混合流如何工作？
【发布时间】：2018-08-02 06:42:49
【问题描述】：

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

这是我的场景。

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

当用户第一次登录时

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

上面的场景有什么步骤错误吗？

【问题讨论】：

【解决方案1】：

对于移动客户端，建议将授权代码流与 PKCE 一起使用。请通读这两个答案，以了解为什么建议使用Link-1 和Link-2。

此外，RFC8252 为原生应用程序提供了一些最佳实践应用程序（移动客户端是原生应用程序。！）。在这方面，建议不要使用网络视图。

这是来自RFC8252-overview的引述

以前，原生应用通常使用嵌入式用户代理（通常通过 Web 视图实现）用于 OAuth 授权要求。这种方法有很多缺点，包括主机应用程序能够复制用户凭据和 cookie 以及用户需要在每个应用程序中从头开始进行身份验证

通过使用网络视图，您失去了 OAuth 2.0 的真正本质。您的客户端应用程序能够掌握最终用户凭据。所以使用浏览器而不是网络视图。（请从link 阅读有关嵌入式用户代理的更多信息）

在您的架构中，您可以启用所有这些，PKCE、授权代码流和使用浏览器而不是 web 视图。但是一旦支持者收到令牌，它应该将它们传递给您的客户。如果你坚持这种架构，那将是一个挑战。

但是，如果您可以让您的移动应用程序完成整个流程，您就可以避免这种复杂性。收到令牌后，您可以通过验证令牌在支持的服务器之间创建连接。此外，当令牌过期时，移动应用会使用刷新令牌来获取新令牌。

【讨论】：

“但是一旦被支持者收到令牌，它应该将它们传递给您的客户端。如果您坚持这种架构，那将是一个挑战。”能否请您详细说明。
@Epistemologist 服务器如何将令牌推送回您的客户端？会有开放的套接字吗？或任何其他推送机制？那将是一个复杂的情况。我宁愿让我的移动应用程序来处理流程并获取令牌。
我同意使用 PKCE 并使用系统浏览器或操作系统提供的代理的混合或身份验证代码流是最好的方法。关于接收响应......这并不是一个真正的挑战，它是一个很好的路径，并且可以使用自定义 URL 方案或本地 HTTP 侦听器来接收本机应用程序中的授权端点响应。 @Epistemologist 图中不正确的一点是移动应用程序/设备将直接与身份服务通信，并且访问令牌将保存在设备上。
@mackie 可以说移动设备将直接与 IdentityServer 通信并接收访问令牌，但我必须将客户端密码保存在不安全的移动应用程序上。这个问题有解决办法吗？
如果移动应用程序直接与身份服务器通信，这意味着授权码由浏览器等前端通道传输，而访问令牌由后端通道接收。我是否认为后端渠道错误？