oauth - 如何实施OAuth 2.0同意对话

是否有实施OAuth 2.0授权服务器的用户同意对话框的最佳做法，特别是在用户同意和重定向到重定向端点之间会发生什么？

根据我的理解，OAuth 2.0同意对话框的目的是让用户有机会阻止恶意客户端在欺骗用户使用授权服务器（或使用现有服务器）对自己进行身份验证后自动获取访问令牌浏览器会话）。这本质上依赖于用户的常识和技术理解。

如果恶意客户端可能跳过/绕过同意对话框或以某种方式自动/绕过单击“确定”按钮的过程，则会失败同意的目的。

OAuth 2.0 RFC中未指定从同意对话框到重定向到客户端的协议流程，因为它被视为实现细节。我想知道是否有任何实施此方法的最佳实践。

我考虑过以下几种选择：

在对话框的HTML中嵌入重定向网址，并在用户点击“确定”时使JavaScript代码打开重定向网址。显然，这只不过是一个美化的直接重定向，它周围有一些HTML和JavaScript。在用户同意之前，对话框已经包含访问令牌（隐式授权）或授权代码，授权服务器永远不知道用户是否已经同意。
“确定”按钮向授权服务器发送新请求，服务器通过重定向到重定向URL进行响应。该请求与授权请求相同，但附加参数是服务器生成的某种秘密（类似于CSRF令牌，可能是授权请求的散列和服务器只知道的密钥）在发送原始授权请求时，恶意客户端是否无状态且无法伪造？）

此外，建议（并且对于本机应用程序，甚至RFC 8252要求）系统的默认浏览器用于授权。如果使用默认浏览器，则可以实施其他措施以防止篡改同意对话框，例如

这些措施可能无法在由恶意应用程序控制的嵌入式浏览器视图中运行，而且正如我所看到的，没有可靠的技术方法来阻止“非标准浏览器”。它要教育用户不要将他们的凭据输入任何非浏览器应用程序（并从应用程序商店中删除此类应用程序等）。

（完全没有任何用户交互的自定义Web客户端不需要考虑，因为它们永远不会超过认证阶段 - 换句话说，某种“浏览器”必须向用户显示，因此用户可以键入在他们的授权服务器凭证中。）

这是否意味着“简单”方法（编号1，嵌入在对话框HTML / JS中的重定向URL）就足够了？

或者是否有必要至少实施第二种方法？这甚至还不够好吗？

实施此对话框的常用方法有哪些？ Facebook和谷歌做了什么？

我的任何假设都不正确吗？