我们拥有基于OAuth2的身份验证基础结构，该基础结构已集成到组织中的各种Web应用程序中。我们也有一个纯本地应用程序，没有自己的中间件，我们希望将身份验证集成到此本地应用程序中。该应用程序已经具有自己的带有本机登录屏幕的内部登录机制，并且我们不想让它开始启动外部组件（例如Web浏览器）以显示登录窗口。我们既是应用程序提供者，又是身份验证提供者，因此对应用程序具有用户凭据可见性的关注是 的问题-我们相信自己不会有意地 用用户的凭据做任何令人讨厌的事情，就像在网站上写登录表单的人一样。 ：-）
我们正在尝试找出如何最好地支持让应用程序继续以现在的方式收集凭据，但是使用它们在我们的身份验证框架中获取身份验证令牌。现在有了这些API，我能看到的唯一方法是将Client Secret烘焙到本机应用程序中，以便它可以使用Resource Owner Password Credentials Grant请求，因为该代码通常会此调用没有服务器端可驻留。这听起来确实有点错误。 :-P
据我所知，OAuth的许多结构并未真正应用于此应用程序，因为它不存在于Web浏览器的上下文中，它没有任何“域”概念，任何形式的“跨域”限制。有人建议也许我们为这个应用程序 just 创建中间件，目的是为了交换令牌的身份验证代码，但是这样做的理由似乎是该中间件理论上应该能够以某种方式审查请求以确定它们是否合法地来自应用程序，而且我看不到有任何方法可以被任何有权访问客户端应用程序代码的人伪造。基本上，这种中间件唯一的目的就是使客户端机密与获取凭据的身份验证代码无关。
一个想到的是，像Windows这样的事情是如何做到的？ Windows很显然使用本地登录形式，但是随后存在一些流程，通过该流程，输入的凭据用于身份验证，并且大概是深入操作系统内部以获取身份验证令牌。有人知道该体系结构是否在任何地方都有文档记录吗？ Microsoft的体系结构选择是否与OAuth2有关系？如果您将应用程序视为没有中间件并且具有自己的本机登录表单的给定应用程序，那么“最佳实践”是什么？
答案 0 :(得分：0)
首先，如果将客户端配置为公共客户端（即，不能存储密码的客户端），则不需要客户端密码即可使用ROPC Grant来获取或刷新令牌。
RFC8252 OAuth 2.0 for Native Apps鼓励通过PKCE使用授权代码流来为您的方案使用本机用户代理。 Okta和Auth0之类的授权服务也已经加入，尽管如果客户端为“ absolutely trusted”，它们仍然建议使用ROPC。
RFC6819 OAuth 2.0 Security不鼓励ROPC，但也说“对于客户端应用程序和授权服务来自同一组织的方案，限制使用资源所有者密码凭据授予”。
因此，尽管安全性判断似乎是授权码+ PKCE是最佳实践，但向用户显示浏览器窗口以登录本机应用程序的UX障碍似乎正在使ROPC保持活力。很难说出UX是否令人讨厌是因为人们不习惯它，还是因为人们不习惯它。