为什么OAuth RFC要求再次传递redirect_uri以交换令牌代码？

Question

假设我的重定向uri和授权代码请求有效,并且我想交换令牌的有效代码,验证我在access_code请求中传递的重定向URI是否与授权代码请求中提供的相同uri匹配有什么好处？

Answer 1

它是为了防止攻击者操纵认证请求，使授权服务器将代码发送到攻击者控制下的URL。

如果只有一个向授权服务器注册的重定向 URI（最佳实践），则这种攻击是不可能的，但是当使用松散类型的匹配时（例如，接受特定域上的任何重定向 URI），那么很可能会发生这种攻击。该域的某些部分可能会被攻击者操纵（例如通过开放重定向、易受攻击的维基、论坛等）来获取code并随后针对合法客户端重放它。强制重定向 URI 到位后，授权服务器在授权请求中看到的重定向 URI 与客户端针对令牌端点使用的重定向 URI 之间现在将不匹配。如果根本没有预先注册重定向 URI，则这种攻击就更加微不足道。

推理是此处规范安全考虑的一部分：https ://www.rfc-editor.org/rfc/rfc6749#section-10.6

当使用授权码授予
类型请求授权时，客户端可以通过“redirect_uri”参数指定重定向URI。如果攻击者可以操纵重定向 URI 的值
，则可以导致授权服务器将资源所有者用户代理重定向到 攻击者使用授权代码
控制的 URI 。

攻击者可以在合法客户端创建帐户并启动授权流程。当攻击者的用户代理被发送到授权服务器以授予访问权限时，攻击者会获取合法客户端提供的授权 URI 并替换

客户端的重定向 URI 与攻击者控制下的 URI
。然后，攻击者诱骗受害者点击受
操纵的链接来授权对合法客户端的访问。

一旦到达授权服务器，受害者就会收到
代表合法且可信客户端的正常、有效的请求提示，
并授权该请求。然后，受害者将被重定向到
攻击者使用授权代码控制的端点
。攻击者通过使用 客户端提供的
原始重定向URI向客户端发送授权代码来完成授权流程。
客户端将授权代码
与访问令牌交换，并将其链接到攻击者的客户端帐户，
该帐户现在可以访问
受害者授权的受保护资源（通过客户端）。

为了防止这种攻击，授权服务器必须确保用于获取授权代码的重定向 URI 与 用授权代码交换访问令牌
时提供的重定向 URI 相同。
授权服务器
必须要求公共客户端，并且应该要求机密客户端
注册其重定向 URI。如果请求中提供了重定向 URI，授权服务器必须根据注册值对其进行验证。