代码之家  ›  专栏  ›  技术社区  ›  Jonathan Gilbert

本地应用程序中第一方身份验证的最佳实践

  •  4
  • Jonathan Gilbert  · 技术社区  · 6 年前

    我们有一个基于OAuth2的auth基础设施,它集成到我们组织内的各种web应用程序中。我们还有一个纯本机应用程序,没有自己的中间件,我们希望将身份验证集成到这个本机应用程序中。此应用程序 我们不想用它自己的登录机制来启动自己的登录窗口。我们既是应用程序提供者又是身份验证提供者,因此应用程序是否能够查看用户的凭据的问题是 较少的 我们相信自己不会 故意 对用户的证书做任何不好的事情,在应用程序中写登录表单和在网站上写登录表单的人是一样的。:-)

    我们正试图找出如何最好地支持应用程序继续以现在的方式收集凭据,但使用它们在我们的auth框架内获取身份验证令牌。现在有了API,我能看到的唯一方法就是将客户机机密烘焙到本机应用程序中,这样它就可以使用资源所有者密码凭据授予请求,因为通常进行此调用的代码没有服务器端可生存。这种感觉 真的错了 不知怎么的。:-P型

    据我所知,OAuth的许多结构并不适用于这个应用程序,因为它不是生活在web浏览器的上下文中,它没有任何“域”的概念,也没有任何类型的“跨域”限制。有人建议我们 创造 此应用的中间件 为了交换令牌的身份验证码,但其基本原理似乎是,该中间件理论上应该能够以某种方式审查请求,以确定它们是否合法地来自应用程序,而且我看不到任何方法可以做到这一点,任何有权访问客户端应用程序的人都无法伪造代码。获取这些证书的目的基本上与客户端的认证无关。

    我们想到的一个想法是,像Windows这样的东西是怎么做到的?显然,Windows使用本机登录形式,但是存在一些流,其中输入的凭据用于身份验证,并且可能在操作系统的内部深处用于获取身份验证令牌。有人知道这个体系结构是否被记录在案吗?微软在这里的架构选择与OAuth2有什么关系吗?如果您将申请视为 鉴于 它没有中间件并且有自己的本地登录表单?

    1 回复  |  直到 6 年前
        1
  •  2
  •   Emerson Farrugia    5 年前

    如果客户端配置为 公共客户 ,即不能存储机密的客户端。

    RFC8252 OAuth 2.0 for Native Apps absolutely trusted ".

    RFC6819 OAuth 2.0 Security

    因此,虽然安全性的结论似乎是授权码+PKCE是最佳实践,但向用户显示浏览器窗口以登录本机应用程序的UX障碍似乎使ROPC保持活力。很难判断用户体验是因为人们不习惯还是因为人们不习惯。