读者在看这篇文章之前，请先了解 Oauth2.0 的 Authorization Code 授权流程，可以看 Authorization Code 授权原理和实现方法
在 Token Enpoint 中，按照 Oauth2.0 的标准，需要传递一个 redirect_uri 参数。然而，代码却只对这个参数做检查，没有其他处理逻辑，这背后的原因是什么呢？这里，涉及到一种针对 redirect_uri 的攻击方法。
我们还是用 A 来代表合作方，用 B 来代表鉴权方。我们知道，在合作开始之前，A 需要向 B 注册 redirect_uri 。假如 A 注册的是 a.com/*，也就是说，a.com 域名下的所有 path 都可以作为合法的 redirect_uri。而实际使用的时候，A 传递的是 a.com/recieve_code 这个 path。
但是，攻击者通过某种方式，控制了 a.com 域名下的一个 path，比如 a.com/attacker，此时会发生什么呢？
攻击者可以做以下事情：
1，攻击者访问 a.com，登录，然后通过点击，触发授权流程
2，此时 A 会打开授权页面，攻击者通过浏览器的地址栏，获取到了整个 url
3，攻击者将 url 中的 redirect_uri 替换成 a.com/attacker，构建出一个新的 url
4，攻击者通过某种方式，诱骗真正的用户点击新的 url
5，用户打开授权页面，看到的都是正常的信息（B 即将授权给 A，以便 A 访问你在 B 的资源），因此点击授权
6，code 被发送到 a.com/attacker，攻击者拿到 code
7，攻击者手动通过浏览器访问 a.com/recieve_code?code=xxxx ，此时 A 会去兑换 access token，然后将这个 access token 跟攻击者的账号绑定在一起（A 可能把 access token 存在 session 里，也可能放在 db 里，不管怎么样，肯定是和当前登录的账号关联起来的）
8，到这里，攻击者就可以访问真正的用户在 B 的资源
下面用图来解释。
首先，在授权之前，用户在 a.com 和 b.com 都是有账号的：
正常的授权流程完成后，应该是这个样子：
但是，经过攻击者这一波操作后，变成了这个样子：
那么，怎么防御这种攻击呢？
方法就是，B 在生成 code 的时候，记录下来，这个 code 是发送给 a.com/attacker 的：
code -> a.com/attacker
然后，当 A 用 code 来兑换 access token 的时候，告诉 B，我这个 code，是从 a.com/recieve_code 收到的：
code <- a.com/recieve_code
B 一比较，就发现这个 code 被人为搬动过，于是拒绝兑换，就可以了。
以上，就是 redirect_uri 这个参数背后的考量。有问题可以直接评论。