Oauth2.0（三）：Access Token 與 Refresh Token

access token 是應用方訪問資源服務器的接口時，須要提供的一個令牌。擁有這個令牌表明着獲得用戶的受權。然而，這個受權應該是臨時的，有必定有效期。這是由於，access token 在使用的過程當中可能會泄露。給 access token 限定一個較短的有效期能夠下降因 access token 泄露而帶來的風險。

然而引入了有效期以後，應用方使用起來就不那麼方便了。每當 access token 過時，應用方就必須從新向用戶索要受權。這樣用戶可能每隔幾天，甚至天天都須要進行受權操做。這是一件很是影響用戶體驗的事情。但願有一種方法，能夠避免這種狀況。

因而 Oauth2.0 引入了 refresh token 機制。refresh token 的做用是用來刷新 access token。鑑權服務器提供一個刷新接口，例如：

http://xxx.xxx.com/refresh?refreshtoken=&client_id=

傳入 refresh token 和 client_id，鑑權服務器驗證經過後，返回一個新的 access token。爲了安全，Oauth2.0 引入了兩個措施：

1，Oauth2.0 要求，refresh token 必定是保存在應用方的服務器上的，而毫不能存放在狹義的客戶端（例如移動 app、PC端軟件） 上。調用 refresh 接口的時候，必定是從服務器到服務器的訪問；

2，Oauth2.0 引入了 client_secret 機制。即每個 client_id 都對應一個 client_secret。這個 client_secret 會在應用方申請 client_id 時，隨 client_id 一塊兒分配給客戶端。應用方必須把 client_secret 妥善保管在服務器上，決不能泄露。刷新 access token 時，須要驗證這個 client_secret。

因而，實際上的刷新接口應該是相似這樣的：

https://xxx.xxx.com/refresh?refreshtoken=&client_id=&client_secret=

不過，實際當中一般不會把client_secret放在url中，具體怎麼傳遞及驗證由各個平臺本身決定。

應用方何時須要用refresh token來刷新access token呢？當應用方調用資源接口，並接收到返回「access token已過時」的錯誤時，應用方應當嘗試用refresh token去刷新access token，而不是讓用戶從新受權。

雖然refresh token也會過時，可是一般有效期很是長。在設計refresh token相關的api時，須要很是慎重地考慮refresh token和client_secret的安全性。

那麼refresh token是怎麼給到應用方的呢？答案是在用戶完成受權時，隨 access token 一塊兒重定向到回調 url，傳遞給應用方。

以上就是refresh token機制。

更多技術文章，請關注我的號：