討論 OAuth 2 的 token 更新策略
這篇是最近在想 OAuth 2 token 更新策略的一些思考，篇名曰「討論」，因為自己也不確定這些想法是不是所謂的最佳實踐，歡迎讀者留言討論。
在 OAuth 2 的各種 flow 中，最終大多會取得兩種 token，access token 和 refresh token，作為代表用戶的令牌存取服務及資源，這兩種 token 的特性如下：
Access Token
- 代表用戶存取服務。
- 有效期短。
- 因為有效期短，比較不用擔心被竊，一般可以存放在 cookie、local storage、session storage、記憶體等處。
Refresh Token
- 用於更新 access token 和 refresh token。
- 除了更新 token 外無法用於存取服務。
- 有效期長。
- 因為有效期長，需要較妥善的保存，一般建議存放在具有 HttpOnly 屬性的 cookie 內，但也還是有些人放在 local storage。
Token 更新
因為 access token 效期短，為了塑造良好的用戶體驗，不要讓用戶頻繁登入，我們必須在客端 app 上利用 refresh token 更新 token，一般而言，更新 token 時不僅會取得新的 access token，也會取得新的 refresh token。
基於前面的條件，我們可以設想出第一版的更新策略。
更新策略第一版
說明如下：
- 用戶點了連結或按了某個按鈕。
- 進入藍色區域，檢查 access token 效期，如果一切順列，直接進入綠色方塊，拿 access token 向服務端要內容或執行某些事務。
- 如果客端根本就沒有 access token，那就進入黃色區域，拿 refresh token 換回一對新的 access token 和 refresh token。
- 如果客端的有 access token，但卻過期了，那一樣拿 refresh token 去換一對新的回來。
- 如果 refresh token 失敗，表示 refresh token 也是過期的，那就只好請用戶重新登入。
- 如果客端自己知道 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 悖論
同場加映 access token 悖論。
前面提過 accsss token 有效期短，較能承受外流的風險，例如一個效期僅一分鐘的 access token，就算外流了，多半也不太恐慌，因為一分鐘後失效了，反之，另一個效期短達一天的 access token 外流，那我們可能會緊張一下。
基於上述的設定，我們可以認定效期越短，安心感越大，因此想要安心感無限大，那效期就要無限短，短到趨近於零，但這樣就失去它的功能了，或許我們可以改用「次數」的觀點看效期，從原本的時間效期改為次數效期，也就是所謂的 one-time token，但 access token 還有一個無狀態的特性，該如何無須管理它的狀態又讓它僅能使用單次，答案或許是類似區塊鏈的技術。