文章收錄在我的 GitHub 倉庫，歡迎Star/fork：
Java-Interview-Tutorial
https://github.com/Wasabi1234/Java-Interview-Tutorial
xx軟件最終是通過訪問令牌請求到我的公衆號裏的文章。訪問令牌是通過授權碼換來的。你有想過爲何要用授權碼換令牌，而不直接頒發訪問令牌呢？
OAuth 2.0 的角色
資源擁有者、客戶端(即第三方軟件)、授權服務和受保護資源。
- 資源擁有者=> 我
- 客戶端 => xx軟件
- 授權服務 -> 公衆號開放平臺的授權服務
- 受保護資源 -> 我的公衆號裏的文章
一定要授權碼嗎?
第 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方法，同時該方法也是被強烈建議通過開發者的後端服務來調用
參考