大白話講解OAuth2.0的客戶端模式Client Credentials

Oauth2.0的客戶端模式

 

1.由Authorization Server提供給各業務系統一個clientID和clientSecret；

2.通過clientID和clientSecret獲取accessToken；

POST /token HTTP/1.1
Host: authorization-server.com
 
grant_type=client_credentials
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx

3. 如果驗證通過，正常返回accessToken如下

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
 
{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create"
}

　　如果驗證不通過，返回的example如下

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
 
{
  "error": "invalid_request",
  "error_description": "Request was missing parameter."
}

4.關於token的選擇包括以下幾種

• 短期的accessToken和長期的refreshToken

這個是官方推薦做法，具有更大的安全性和靈活性;

這種場景下，可以讓accessToken有效期從幾個小時到幾周，refreshToken是長期有效要求比acessToken有效期長;

當accessToken失效后，可以通過refresshToken獲取新的accessToken;

這種方式多用在不打算提供數據庫處理accessToken而是通過本地加解密方式從而提高系統響應時間、有效降低泄露accessToken的風險、考慮到refreshToken邏輯實現比較讓人討厭，所以需要服務方提供sdk封裝refresh的操作。

•  短期的accessToken且不提供refreshToken

這種選擇下accessToken有效性可以維持從當前session至幾周，自由選擇；

但是規范是要求到期后，需要用戶重新登錄系統，之后重新通過認證獲取accessToken，讓用戶參與到accessToken有效期的維護中。

• 永不過期的accessToken

這種是最簡單也最容易讓人接受的方式，但是必須做到能隨時讓某個accessToken失效；

如果token泄露了不會有大的風險、可以讓調用方更容易的實現認證、有數據同步的需求優先考慮

 

5. 刷新accessToken

如果采取【短期的accessToken和長期的refreshToken】，那么就必須提供刷新的接口，刷新接口必須校驗必輸項，驗證refreshtoken有效性，驗證clientid和clientsecret匹配性，之后提供新的accessToken

POST /oauth/token HTTP/1.1
Host: authorization-server.com
 
grant_type=refresh_token
&refresh_token=xxxxxxxxxxx
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx