討論 OAuth 2 的 token 更新策略

• 代表用戶存取服務。
• 有效期短。
• 因為有效期短，比較不用擔心被竊，一般可以存放在 cookie、local storage、session storage、記憶體等處。

• 用於更新 access token 和 refresh token。
• 除了更新 token 外無法用於存取服務。
• 有效期長。
• 因為有效期長，需要較妥善的保存，一般建議存放在具有 HttpOnly 屬性的 cookie 內，但也還是有些人放在 local storage。

Token 更新

更新策略第一版

說明如下：

1. 用戶點了連結或按了某個按鈕。
2. 進入藍色區域，檢查 access token 效期，如果一切順列，直接進入綠色方塊，拿 access token 向服務端要內容或執行某些事務。
3. 如果客端根本就沒有 access token，那就進入黃色區域，拿 refresh token 換回一對新的 access token 和 refresh token。
4. 如果客端的有 access token，但卻過期了，那一樣拿 refresh token 去換一對新的回來。
5. 如果 refresh token 失敗，表示 refresh token 也是過期的，那就只好請用戶重新登入。
6. 如果客端自己知道 refresh token 過期，那也是請用戶重新登入。

在這看似有點亂又不太亂的策略中，客端 app 需要管理 access token 和 refresh token 的狀態，也就是知道他們的有效期，但還記得嗎，refresh token 是 HttpOnly 的 cookie，JS 讀不到。

況且不論我知不知道 refresh token 的有效與否，都得走入「Refresh token」這一步，只差在是我主動發現 refresh token 過期而導向登入頁，或是直接走進「Refresh token」方塊，失敗再導向登入頁。站在用戶的角度，他是感受不到這兩條路的差異的，一切都只發生在主客端程式的對話中，基於以上，我們可以把黃色區域整塊拿掉：

於是簡化成第二版。

更新策略第二版

第二版清爽多了，也減少客端 app 的邏輯，不用去管 refresh token 還有沒有，只管 access token 存不存在、有沒有過期， 不存在、過期了，就去「Refresh token」方塊跑一下，成功就成功，失敗就帶用戶重新登入。

同樣的，如果藍色方塊有問題都跑去「Refresh token」，那何不連藍色方塊都省掉：

於是我們有了第三版。

更新策略第三版

第三版的邏輯不由分說，無須任何判斷 token 存在、有效的邏輯，不關心狀態，只無腦更新，錯了就抓用戶去重新登入。

第三版夠傻瓜也夠聰明，但未必可行，紅色方塊右上的小圖示說明他們是要走網路的，無腦更新，表示服務端必須回應，如果客端 app 人很多，那相當於對服務端發動 DDoS 攻擊，要嘛就是服務端被打爆，要嘛就是用戶被封鎖。

這種作法主客端交互開銷巨大，對服務端來說，要考慮的是 token 的生成效率，token 的主流選擇是 JWT，JWT 是以 Base64 和 HS256 為基礎算出來的，也就是說服務端需要高效率的 Base64 與 HS256 解編碼演算方案，每種語言都有多樣的 Base64、HS256 編解碼器，也可以利用 APM 監控 refresh token 端點的負載，再視需要做優化。

Access Token 悖論