近年来，随着 OAuth 的出现（它也可能影响其他框架），我注意到移动和桌面应用程序出现了一种趋势，即请求用户使用 3rd 方身份验证提供程序（通常是 Twitter 等社交帐户）注册或登录，脸书或谷歌。当我无法信任正在输入凭据的应用程序时，问题就出现了，因为开发人员已将浏览器嵌入到应用程序拥有的对话框/窗口中，而我无法知道我正在查看的页面是否是合法的登录页面，或者用户代理（浏览器和顶层）是可以信任的。
我也不是在谈论来自小型独立开发者的应用程序，我说的是广受信任的公司的软件（至少在我花费大部分时间的软件开发社区中）。我在过去几周看到的一些例子：
- Atlassian Sourcetree允许您使用 Google 帐户登录 - 在 Atlassian 窗口中
- Postman Google 登录发生在 Postman 窗口中
- Microsoft Visual Studio 和 Office 使用您的 Microsoft 帐户执行此操作（当然，这更受信任，因为该应用程序归身份验证提供商所有，但它仍然认可该过程）
- 例如，某些应用程序会要求您在其应用程序内的浏览器窗口中登录 Paypal
过去关于移动应用程序的类似问题（但问题不仅限于移动）：
与桌面应用程序相关的一个问题：
切线相关的是在 Web 应用程序中使用 iframe：
当我从应用程序空间转移到网络以进行身份验证、获取令牌并返回应用程序时，这对我来说是一个信任问题。我可能足够信任这些公司来安装他们的软件，但不足以将我的 Google 帐户的主密钥（出于所有意图和目的）输入到他们的软件中。
在进一步研究这个问题时，我发现这个 IETF 草案指出：
嵌入式用户代理是授权本机应用程序的另一种方法。但是，根据定义，它们对于授权服务器的第三方使用是不安全的，因为托管嵌入式用户代理的应用程序可以访问用户的完整身份验证凭据，而不仅仅是用于应用程序的 OAuth 授权授权。
编辑：上面的草案成为RFC8252，日期为 2017 年 10 月，感谢@Geir 指导我。
还有一个较旧的指令 RFC6749（日期为 2012 年 10 月），其中还提到了其他有趣的花絮：
嵌入式用户代理带来了安全挑战，因为资源所有者在一个身份不明的窗口中进行身份验证，而无法访问大多数外部用户代理中的视觉保护。嵌入式用户代理教育最终用户信任身份不明的身份验证请求（使网络钓鱼攻击更容易执行）。
我的问题：
我是否担心这是网络钓鱼和 MITM 攻击的增长机会（中间的假冒或劫持浏览器实时窃取凭据和/或令牌，也击败了 2FA）？与其说受信任的软件本身很可能是恶意软件，不如说是广泛使用会阻止用户验证端到端信任，纵容（甚至鼓励）用户盲目地将凭据输入到任何需要它们的应用程序中？
我认为上面引用的最后一部分无疑是肯定的，但我对进一步的评论和观点感兴趣，尤其是作为一名软件开发人员。
明显的“正确”方法是将用户转发到他们受信任的浏览器进行身份验证，但这可能是一个糟糕的用户体验，并且实际上并不能解决问题（恶意开发人员可以从主窗口打开一个窗口）看起来像 Chrome 的应用程序，但实际上不是——事实上，来自主浏览器窗口的用户会话没有被保留，以及其他视觉提示可能会被大多数人忽视）。
是否有更好的方法来设计应用程序的用户体验，以便用户可以确定他们在应用程序内使用受信任的软件堆栈（应用程序和渲染引擎）？是否应该以难以模仿的方式对此类身份验证请求进行设备级或系统级处理？
我并没有真正涉足安全领域，只是一个潜伏者，这是业内众所周知的问题吗？是否有努力遏制这种身份验证流程？