圖文+代碼講解帶你攻克OAuth 2.0授權流程的三座大山（下）

用戶端憑據許可類型的關鍵流程，就如下兩大步：

1. 三方軟體xx通過後端服務請求授權服務，

   grant_type = client_credentials

   ，通知授權服務使用三方軟體憑據方式去請求通路。

1. 在驗證

   app_id

   和

   app_secret

   後，生成

   access_token

   傳回。

适用場景

在擷取一種不屬任何第三方使用者的資料時，無需類似我這樣的進階使用者參與。

3 隐式許可

若我使用的xx軟體沒有後端服務呢，就是在浏覽器執行，比如純甄的JS應用。可了解為三方軟體直接嵌入浏覽器。

這時的xx軟體對浏覽器已無任何秘密可言，也無需應用密鑰app_secret，更無需再通過授權碼code換取通路令牌access_token。因為使用授權碼的目的之一，就是把浏覽器和三方軟體的資訊隔離，確定浏覽器看不到三方軟體最重要的通路令牌access_token。

是以，隐式許可授權流程安全性降低很多。在授權流程中，沒有服務端的xx相當于嵌入浏覽器，通路浏覽器的過程相當于接觸了xx的全部。

1. 使用者通過浏覽器通路三方軟體xx。此時，三方軟體xx實際上是嵌入浏覽器中執行的應用程式
2. 該流程和授權碼類似，隻是response_type值變成token，告訴授權服務直接傳回access_token值。

隐式許可是唯一在前端通信中要求傳回access_token的流程。

1. 生成acccess_token的值，通過前端通信傳回給第三方軟體小兔。

授權類型的選型

參考

• https://iot.mi.com/new/doc/cloud-development/miot-access/oauth
• 除了授權碼許可類型，OAuth 2.0還支援什麼授權流程？
• OAuth2 RFC6749中文翻譯