首页 文章

混合流与移动应用程序如何工作?

提问于
浏览
3

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

这是我的情景 .
enter image description here

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

用户第一次登录时

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

  • 将打开移动网络视图

  • 用户将使用凭据登录

  • 身份服务器将Id令牌和访问代码发送到后端服务器

  • 后端服务器将交换Id令牌和访问令牌的访问代码

将向移动应用程序返回什么标记以提供该用户有效 . 并且后端服务器是否有责任获取新的访问令牌而不提示用户重新登录,直到用户退出?

在上面的场景中有任何步骤错误吗?

1 回答

  • 2

    对于移动客户端,建议使用授权代码流和PKCE . 请仔细阅读这两个答案,掌握一些想法,为什么建议Link-1Link-2 .

    此外,RFC8252为Native Apps提供了一些最佳实践应用程序(移动客户端是本机应用程序 . !) . 在此,建议不要使用Web视图 .

    这是RFC8252-overview的报价

    以前,本机应用程序通常使用嵌入式用户代理(通常通过Web视图实现)来执行OAuth授权请求 . 这种方法有许多缺点,包括主机应用程序能够复制用户凭据和cookie以及需要在每个应用程序中从头开始进行身份验证的用户

    通过使用Web视图,您将失去OAuth 2.0的真正本质 . 您的客户端应用程序能够掌握最终用户凭据 . 因此,请使用浏览器而不是Web视图 . (请从此link了解有关嵌入式用户代理的更多信息)

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

    但是,如果您可以使移动应用程序完成整个流程,则可以避免这种复杂性 . 收到令牌后,您可以通过验证令牌在备用服务器之间 Build 连接 . 此外,当令牌过期时,移动应用程序将使用刷新令牌来获取新令牌 .

相关问题