讀者在看這篇文章之前，請先了解 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 這個引數背後的考量。有問題可以直接評論。