文章收錄在我的 GitHub 倉庫，歡迎Star/fork：
Java-Interview-Tutorial
https://github.com/Wasabi1234/Java-Interview-Tutorial

xx軟體最終是通過訪問令牌請求到我的公眾號里的文章，訪問令牌是通過授權碼換來的，你有想過為何要用授權碼換令牌，而不直接頒發訪問令牌呢？

OAuth 2.0 的角色

資源擁有者、客戶端(即第三方軟體)、授權服務和受保護資源，

一定要授權碼嗎?

第 4 步授權服務生成授權碼，倘若我們不要授權碼，這步直接回傳訪問令牌access_token ，那就不能重定向，因為這樣會把安全保密性要求極高的訪問令牌暴露在瀏覽器，增加訪問令牌失竊風險，這顯然不行的呀！即若無授權碼，就只能把訪問令牌發給第三方軟體的后端服務：

看著好像沒問題？我訪問xx軟體，xx軟體說要排版文章我得給它授權，不然vx公眾號不干，然后xx軟體就引導我跳轉到了公眾號的授權服務，到授權服務之后，開放平臺驗證xx的合法性及我的登錄狀態后，生成授權頁面，我趕緊掃碼同意授權，于是開放平臺知道可以把我的文章資料給xx軟體，

于是，開放平臺生成訪問令牌 access_token，并且通過后端服務方式回傳給xx軟體，xx就能正常作業，

但是當我被瀏覽器重定向到授權服務，我和xx間的連接就斷了，相當于此時我和授權服務建立連接后，將一直“停留在授權服務頁面”，我再也沒有重連到xx，

但這時xx已拿到我授權后的訪問令牌，也使用訪問令牌獲取了我的號里的文章資料，這時，考慮我的感受，xx應該要通知到我，但是如何做呢？現在連接可是斷了的呀！
為了讓xx通知到我，我必須跟xx重建 “連接”，即第二次重定向，我授權后，又重新重定向回到xx的地址，這樣我就跟xx有了新連接，

為重建連接，又不能暴露訪問令牌，就有這樣的臨時、間接憑證：授權碼，因為xx最終要拿到高安全要求的訪問令牌，并非授權碼，授權碼可以暴露在瀏覽器，
有了授權碼，訪問令牌可以在后端服務間傳輸，同時還可重建我&xx間的連接，
所以，通過授權碼，既考慮了我的用戶體驗，又考慮了通信安全，

執行授權碼流程時，授權碼和訪問令牌在xx和授權服務間到底怎么流轉的？

間接通信就是指獲取授權碼的互動，

我：“xx，我要訪問你了，”
xx：“我把你引到授權服務，我需要授權服務給我一個授權碼，”
授權服務：“xx，我把授權碼發給瀏覽器了，”
小兔軟體：“ 那我從瀏覽器拿到了授權碼，”

xx和授權服務間，并無直接通信，而是通過中間人(瀏覽器).

授權碼換取訪問令牌的互動，是“直接”的，

三方軟體xx獲取到授權碼后，向授權服務發起獲取訪問令牌 access_token 的請求，

三方軟體要代表資源擁有者去訪問受保護資源
授權服務負責頒發訪問令牌，受保護資源負責接收并驗證訪問令牌，

比如獲取用戶登錄態資訊的程序：

通過 wx.login(Object object) 獲取登錄憑證 code，該步是在小程式內部通過呼叫微信提供的 SDK 實作的
再通過該 code 換取用戶的 session_key 等資訊，即官方檔案的 auth.code2Session 方法，同時該方法也是被強烈建議通過開發者的后端服務來呼叫

參考

https://leokongwq.github.io/2017/02/28/why-oauth2-use-authorization-code.html
https://developers.weixin.qq.com/miniprogram/dev/api-backend/open-api/login/auth.code2Session.html
https://segmentfault.com/q/1010000014642301
https://tools.ietf.org/html/rfc6749

轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/182286.html

標籤：其他