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

Question

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

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

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

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

Answer 1

FWIW 如果客户端配置为公共(public)客户端(即无法存储 key 的客户端)，您不需要客户端 key 即可使用 ROPC 授权来获取或刷新 token 。
RFC8252 OAuth 2.0 for Native Apps鼓励在您的场景中使用 native 用户代理，将授权代码流与 PKCE 一起使用。 Okta 和 Auth0 等授权服务也加入了进来，尽管如果客户端是“absolutely trusted”，它们仍然推荐 ROPC。
RFC6819 OAuth 2.0 Security不鼓励 ROPC，但也表示“将资源所有者密码凭据授予限制在客户端应用程序和授权服务来自同一组织的情况下”，即第一方应用程序。
因此，虽然安全判决似乎是授权码+PKCE 是最佳实践，但向用户显示浏览器窗口以登录 native 应用程序的 UX 障碍似乎使 ROPC 保持活力。很难判断用户体验是否令人不快，是因为人们不习惯它还是因为人们无法习惯它。