我对 OAuth2 的用户代理流程有 2 个问题。（OAuth2 的用户代理流程的当前 RFC 草案在这里： https ://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-11#section-2.2 ）
1)
步骤 C：必须在片段中给出访问令牌，因为只有用户代理（浏览器）才能访问它。为什么它会到达服务器端（如果有任何服务器端）会出现这样的问题，还有一些简单的解决方法，以便客户端可以将它传递给服务器端（cookie、隐藏字段、. ..)
2)
我想实现 OAuth2 用户代理流程，但是使用两条腿的版本（request_token 就足够了，消费者应用程序可以充当他的用户，因此无需在服务提供商处对用户进行身份验证）
OAuth2 的用户代理流程和两条腿的版本相结合，我有一个主要的安全漏洞：
Web 浏览器处理所有重定向。这意味着即使服务提供商认为它将用户发送到指定的主机和域，该主机和域对于用户重定向到他们自己的机器或任何地方都是微不足道的，通过调整他们的 DNS 设置或 /etc/hosts文件。
让我们看看 3-legged 和 2-legged 版本：
使用 3-legged OAuth 这不是一个主要问题，因为用户仍然需要在服务提供商处进行身份验证。攻击者可能会设置一个通向他的机器的虚假域，但他仍然需要用户的凭据。他可以将用户引诱到他的域，但他必须做出域查找的结果（由用户的用户代理完成），他只能通过访问用户的机器来做到这一点（这更困难）
然而，使用 2-legged OAuth：攻击者可以轻松地使用无辜消费者应用程序的域设置 localhost (/etc/hosts) 并获取 request_token。用户与它无关。攻击者现在可以代表无辜消费者应用程序的所有用户进行调用。有谁知道如何确保这个差距？
问候，基卢斯