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

Question

我们有一个基于 OAuth2 的身份验证基础设施，该基础设施已集成到我们组织内的各种 Web 应用程序中。我们还有一个没有自己的中间件的纯原生应用程序，我们希望将身份验证集成到这个原生应用程序中。这个应用程序已经有自己的内部登录机制和一个本地登录屏幕，我们不希望它启动外部组件，如 Web 浏览器来显示登录窗口。我们是应用提供商和权威性提供两个，因此具有可识别性应用的关注到用户的凭据是少一个问题-我们相信自己，不刻意用用户的凭据做任何不妥当的事情，在应用程序中编写登录表单和在网站上编写登录表单的人是同一个人。:-)

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

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

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

Answer 1

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

适用于本机应用程序的 RFC8252 OAuth 2.0鼓励在您的场景中使用本机用户代理，并使用带有 PKCE 的授权代码流。像 Okta 和 Auth0 这样的授权服务也已经加入，尽管如果客户端“绝对可信”，他们仍然推荐 ROPC。

RFC6819 OAuth 2.0 安全性不鼓励 ROPC，但也表示“限制在客户端应用程序和授权服务来自同一组织的场景中使用资源所有者密码凭据授予”，这些场景是第一方应用程序。

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