通过不验证redirect_uriOAuth 提供程序，可以将其用作理想的网络钓鱼向量。这redirect_uri是 OAuth 提供者使用的地址，作为access_token通过浏览器重定向提供的位置。流行的 OAuth 提供商 Facebook遇到了 许多与 OAuth 重定向相关的漏洞。

在此攻击中，攻击者向受害者提供一个指向受害者信任的身份验证门户（如 Facebook）的 URL，并通过使用此身份验证门户，将受害者的秘密访问令牌传递到攻击者控制的 HTTP 服务器。

身份验证是关于意图的，诱使用户允许访问非预期资源是一个漏洞。

根据评论编辑。我以前认为 OP 在授权请求期间指的是 redirect_uri 验证，并链接到此处的攻击示例。我已经更新了下面的答案。

TL;DR：如果需要注册静态重定向 URL 并由提供者严格匹配，我认为在访问令牌请求期间不需要 redirect_uri。

注册要求( 3.1.2.2)表明应该注册重定向 URI。但是，并非所有提供者都执行重定向 URI 的完全匹配，尽管规范要求它。OAuth 规范尝试了多种对策来防止这些可能性，在威胁模型和安全考虑 RFC (5.2.4.5)中描述了 redirect_uri <-> 授权代码绑定要求。

例如，GitHub 匹配了 URL 前缀，这导致了Egor Homakov在此处描述的攻击。特别是，漏洞 1 和漏洞 2 允许攻击者使用列入白名单的重定向 URI 来获取代码，然后使用该代码完成回调流程并获得对受害者帐户的访问权限。在这种情况下，客户端 (Gist) 将正确的重定向 URI 发送到提供者 (GitHub)，如果 GitHub 检查以确保重定向 URI 与授权请求期间使用的相同，则 GitHub 将不会授予访问令牌：

它是有缺陷的：无论客户端发送什么redirect_uri 来获取令牌，提供者都会以有效的access_token 响应。

攻击者可以劫持为“泄露的”redirect_uri 发布的授权代码，然后将泄露的代码应用于真实客户端的回调以登录受害者的帐户。

总而言之，在获取访问令牌时需要 redirect_uri，以确保从重定向到攻击者可以插入代码的页面的泄露代码不会立即破坏 OAuth 流程。Egor还描述了攻击向量的更完整概述：

攻击很简单：在客户端的域上找到一个泄漏页面，插入跨域图像或指向您网站的链接，然后将此页面用作redirect_uri。当你的受害者加载精心设计的 URL 时，它会将他发送到leaking_page?code=CODE 并且受害者的用户代理将在 Referrer 标头中公开代码。

现在，您可以在实际的 redirect_uri 上重新使用泄露的授权代码来登录受害者帐户。

补救措施：灵活的 redirect_uri 是一种不好的做法。但是，如果您需要它，请为您发出的每个代码存储 redirect_uri 并在创建 access_token 时对其进行验证。

正如 Egor 所说，链接 1：

所有 oauth 漏洞利用都是基于篡改 redirect_uri 参数。

和链接2：

向量 2。如果规范实施得当，那么将 redirect_uri 篡改为其他“泄漏”值是没有意义的。因为要获得访问令牌，您必须使用客户端凭据发送 redirect_uri 值。如果实际的redirect_uri 是“泄漏的”并且不等于真正的redirect_uri 客户端将无法获得此代码的access_token。

redirect_uri是客户端接收的回调Authorization Code。客户将任何带来代码的人视为资源所有者。

攻击者可以redirect_uri在步骤 A 中用恶意的替换来获取代码。然后他可以重建并触发uri来劫持属于Resource Owner的会话。

但是，每个代码都有一个对应redirect_uri的发布时间，即代码将根据redirect_uri步骤C中的污染计算。

请注意，步骤 D 中的请求是由客户端发出的。它将始终使用正确的redirect_uri. 最后，授权服务器发现代码与 uri 不匹配，因此在步骤 E 中不会响应任何令牌。