文章收錄在我的 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