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