token & refresh token 機制總結

廢話

我在專案上寫了個配置頁面，之前很簡單直接登入，畢竟配置頁面自己人用就沒有做token機制，後來公司的安全稽核不過，現在要加上token和重新整理機制。小結一下。

token和重新整理機制

token機制就是在登入成功後返回一個token，並快取起來，之後每個請求頭裡帶上token，後端驗證不通過返回401，前端就直接跳轉到登入頁。這樣就能防止直接訪問某個連結就能跳到登入頁的尷尬局面。

token重新整理機制就是在使用的時候使用某個機制使得這個token不過期，不會跳轉到登入頁。而沒有使用的時候token會過期，他隔得太久了再調介面就是401，就會跳到登入頁。

兩種token重新整理機制

第一種（後端提供重新整理介面）

客戶端 服務端
--- 傳送username & password --->
<--- 返回accesstoken & refreshtoken ---
--- 訪問介面攜帶accesstoken --->
<--- 返回資訊/401 ---
--- accesstoken過期訪問重新整理介面攜帶refreshtoken --->
<--- 返回新的accesstoken/401 ---
--- 訪問介面攜帶新的accesstoken --->
<--- 返回資訊/401 ---

這種情況下 refreshtoken可以設定的時間長一點，而accesstoken設定的時間短一點，我們固定一個使用者活躍週期；

活躍週期 = token週期 * 2 ；

eg：活躍週期(at);token週期(et);accesstoken(5 min);refreshtoken(1 day);

使用者在15:00登入，返回token生命週期(et)是[15:00-15:05];使用者活躍週期為[15:00-15:10];

如果使用者在15:06呼叫介面，攜帶accesstoken會返回401過期，此時在活躍週期範圍內，則呼叫refreshtoken重新整理介面，返回新的accesstoken;

此時：et[15:06-15:11],at[15:06-15:16];

如果使用者在15:17分呼叫介面攜帶accesstoken會返回401過期，此時不再活躍週期內，則跳轉到登入頁；

第二種（靠前端cookie實現）

客戶端 服務端
--- 傳送username & password --->
<--- 返回accesstoken ---
cookie儲存設定過期時間
--- 訪問介面攜帶accesstoken --->
<--- 返回資訊/401 --->
呼叫成功，覆蓋延長cookie過期時間 --->

這種情況後端accesstoken可以設定的時間長一點；

前端將token存在cookie中，維護一個過期時間，每次呼叫介面成功後就覆蓋延長這個過期時間，不呼叫介面的時候自然會超時了；

以上；