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

Question

我们有一个基于 OAuth2 的身份验证基础架构，它集成到我们组织内的各种 Web 应用程序中。我们还有一个没有自己的中间件的纯原生应用程序，我们希望将身份验证集成到这个原生应用程序中。这个应用程序已经有自己的内部登录机制和一个本地登录屏幕，我们不希望它开始启动 Web 浏览器等外部组件来显示登录窗口。我们既是应用程序提供者又是身份验证提供者，因此应用程序对用户凭据的可见性的担忧不是问题——我们相信自己不会故意对用户的凭据做任何不愉快的事情，在应用程序中编写登录表单与在网站上编写登录表单是同一个人。:-)

我们正在尝试找出如何最好地支持让应用程序继续以现在的方式收集凭据，但使用它们在我们的身份验证框架内获取身份验证令牌。现在有了 API，我能看到的唯一方法是将客户端密钥烘焙到本机应用程序中，以便它可以使用资源所有者密码凭据授予请求，因为通常会生成的代码这个调用没有服务器端。不知何故，这感觉真的不对。:-P

据我所知，OAuth 的许多结构并不真正适用于这个应用程序，因为它不是生活在网络浏览器的上下文中，它没有任何“域”的概念，也没有任何形式的“跨域”限制。有人建议，也许我们只是为这个应用程序创建中间件出于交换令牌的身份验证代码的目的，但这样做的理由似乎是这个中间件理论上应该能够以某种方式审查请求以确定它们是否合法地来自应用程序，我看不出有什么办法任何有权访问客户端应用程序代码的人都无法伪造。基本上，此类中间件的唯一目的是使客户端密钥与获取凭据的身份验证代码无关。

我们想到的一个想法是，像 Windows 这样的东西是如何做到的？Windows 非常明显地使用本机登录表单，但随后存在一些流程，其中输入的凭据用于身份验证，并且可能在操作系统的内部深处，用于获取身份验证令牌。有人知道这种架构是否记录在任何地方？微软在这里的架构选择是否与 OAuth2 有任何关系？如果您认为应用程序没有中间件并且有自己的本机登录表单，那么应用程序的“最佳实践”是什么？

标签： authenticationoauth-2.0native

Answer 1

FWIW 如果客户端配置为公共客户端（即无法存储机密的客户端），则不需要客户端机密即可使用 ROPC 授予获取或刷新令牌。

适用于本机应用程序的 RFC8252 OAuth 2.0鼓励在您的场景中使用本机用户代理，将授权代码流与 PKCE 一起使用。Okta 和 Auth0 等授权服务也加入了进来，尽管如果客户端“绝对受信任”，它们仍然推荐 ROPC。

RFC6819 OAuth 2.0 Security不鼓励 ROPC，但也表示“将资源所有者密码凭证授予限制在客户端应用程序和授权服务来自同一组织的情况下”，即第一方应用程序。

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