我正在学习OAuth2，并阅读了四种不同的授予类型，但是我很难看清如何将这些流中的一个用于不希望打开OAuth2的第一方移动本机应用程序本机浏览器。
赠款类型之外：
隐式授予-不切实际，因为您无法获得刷新令牌，并且您无法确保只有您的应用程序或授权的客户端才能获得访问令牌。
资源所有者密码流-您不能确保只有您的应用程序或授权的客户端才能获得访问令牌。
客户凭据授予-与该用例无关。
这将保留授权码授予。但是，您不能使用客户机密，因此必须将其保留。
这使此流程类似于隐式流程，但是现在授权服务器可以将重定向URI白名单用于某种类型的客户端身份验证，并且应用程序将获取刷新令牌。
您似乎可以在移动操作系统中注册URI方案，该方案可用作重定向URI，以在身份验证重定向上打开您的应用。问题在于非法的应用程序可能会欺骗响应您的应用程序URL方案。
添加PKCE似乎可以确保只有启动流程的应用程序才能使用从授权服务器返回的授权代码。我不确定这与使用传递给授权端点的状态令牌有何不同。
这些似乎依赖于相信用户只会从正确的应用程序开始其登录流程吗？
您现在还可以将universal links用于重定向URI，以确保只有您的应用程序可以处理重定向。这是否消除了对PKCE的需求？
即使采用这些方案，您也必须通过设备上的外部用户代理来完成身份验证流程。
来自Facebook，Twitter，Instagram和Google的大多数主要的第一方应用程序都不使用浏览器登录。您直接在其应用程序中输入凭据。
This RFC指出，本机应用程序应使用外部用户代理（浏览器）来进行身份验证流程。
这对我来说很有意义，因为不应将移动本机应用程序视为能够存储客户端机密。
那么这些主要应用程序如何确保只有您的第一方应用程序可以进行嵌入式登录并且其他所有人都必须使用OAuth流的登录流程？