为什么oauth 2.0规范里先后两次提交并验证redirect_uri

最新推荐文章于 2025-07-02 15:46:23 发布

原创最新推荐文章于 2025-07-02 15:46:23 发布 · 9.9k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#oauth #redirect_uri

安全专栏收录该内容

1 篇文章

订阅专栏

OAuth 2.0规范要求在获取access token时验证redirect_uri，以防止授权码被拦截导致的安全风险。redirect_uri是接收authorization code的关键，一旦被篡改，攻击者可能利用code冒充合法用户。验证机制在code被泄露后提供补救，确保redirect_uri与之前记录的一致，保护用户免受session劫持。不同服务商对redirect_uri的管理方式各异，有的仅接受注册时填写的地址，有的允许特定子目录。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

耗子写了篇关于 oauth 的文章，其中第二个bug没有看懂。翻了原文又翻了规范，后来才想通。

原文是 Bug 2. Lack of redirect_uri validation on get-token endpoint 换token（指的是access token）的时候缺少重定向地址的校验。

OAuth 2.0的规范 http://tools.ietf.org/html/rfc6749#section-4.1 也提到必须校验：

(E) The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C).

redirect_uri这个重定向地址是让第三方接收authorization code（授权码）来换access token的。对于第三方而言，谁给它授权码谁就是合法用户，后续将与之建立http会话回吐用户的信息。所以一旦这个地址被攻击者改了，code就会被拦截，真正的用户被重定向到了攻击者的页面，正常流程因此中断；而攻击者就可以拿着code重新拼装好redirect_uri往浏览器里一贴，无需密码他就成了合法用户，完成了session劫持。

redirect_uri是如此敏感，有个办法可以在它leak（也就是被改掉）之后补救：第三方在换token的时候是拿着用户给的code，加上自己受信的redirect_uri一起提交给服务提供方做验证。如果之前服务提供方在前面返回code的时候，code是基于异常的redirect_uri计算出来的，那么这一步重新校验就可以知道两者不匹配。

Egor在这儿说redirect_uri应该是个常量，看了下各家都严格做了限定。国内的qq和豆瓣是固定用第三方注册时填写的地址；google是可以注册时填多个，但必须使用其中一个；github是必须使用注册时的地址，或该地址的子目录（因此给了攻击者机会）。