討論 OAuth 2 的 token 更新策略
更新於 發佈於 閱讀時間約 5 分鐘
這篇是最近在想 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 還有一個無狀態的特性，該如何無須管理它的狀態又讓它僅能使用單次，答案或許是類似區塊鍊的技術。
為什麼會看到廣告
留言0
查看全部
你可能也想看
Google News 追蹤
前言
本篇要用 Token-2022 和 solana cli 來鑄造一個新的代幣叫做TYC。
如前篇所述，Token-2022 與 Spl Token 是不同的 Program，所以在呼叫的時候要特別註明以示明區別。
Token-2022 Program ID 地址: TokenzQdBNb
前兩篇講了SPL Token與Account Model，現在要正式介紹token extension。
Token Extension Program（以下簡稱TEP） 原名 Token 2022，是一個基於原本Token Prgram（以下簡稱TP）的擴充版本。TEP被部署到的地
上一篇提到要在Solana上鑄造新的token需要使用到token program，功能較為陽春。隨著各種新需求的增加同時兼顧安全性的目的，一個新的token program - token 2022 （另名token extension）被開發出來，發佈在一個新的地址上。
Token 2022在
請新用戶參考新訂用戶須知並填寫Trading View個人帳號。對於續訂用戶，我們會延長您的權限，無需填寫問卷。請耐心等待通知。在等待權限開通的過程中，您可以先閱讀趨勢光譜列車區內的文章。若有任何個別問題，可發信cmoneyxiaop@gmail.com討論。
在串接第三方 API時，需要定期刷新 token，那有沒有辦法針對 request 和 response 做配置，在 token 過期時先做刷新、再做請求呢？本文要介紹利用 axios 套件提供的攔截器刷新 token 的作法。
為什麼要登出使用者？
安全性：防止未經授權的人，在使用者暫離時使用系統，這在公用或共享電腦的環境中尤其重要。
資料保護：只要使用者處於登入狀態，就會暴露在個人資料被他人操縱或利用的風險中，因此登出閒置使用者對資安也很重要。
如何在 Vue 3 專案中實作此功能？
當您在vCenter上發現Root使用者密碼過期的訊息時，該如何解決呢？本文將介紹如何透過SSH進入系統並立即變更密碼，以及如何將密碼設定成永不過期，避免再次遇到此問題。
前言
這篇文章分享cookie、sessionStorage、localStorage、session的差異，因為前後端溝通常用的就這幾個，我比較常用的是cookie或session，但也是有可能會用到sessionStorage或localStorage的時候，因此想說這邊做個紀錄比較他們的差別
權限管理=新增、修改、刪除+審核
通常，這種程式的設計會包含權限管理，其中包括現場修改、刪除等三大類功能。然而，根據經驗，我們還需要關注另一類功能，即審核權限。
審核不執行新增
審核權限通常不執行新增的動作，僅限於某些欄位的輸入。新增、修改、刪除這些操作基本上是容易理解的。也就是說，對於這個工
授權碼模式連線流程
用戶端請求自己的伺服器。
伺服器發現用戶沒登入，就導向認證伺服器。
認證伺服器顯示授權頁面，等待用戶授權。
用戶確認授權後，授權頁面會向認證伺服器請求授權碼。
用戶獲取授權碼。
用戶將授權碼傳給伺服器。
伺服器拿授權碼向認證伺服器取得token。
應用註冊
前言
本篇要用 Token-2022 和 solana cli 來鑄造一個新的代幣叫做TYC。
如前篇所述，Token-2022 與 Spl Token 是不同的 Program，所以在呼叫的時候要特別註明以示明區別。
Token-2022 Program ID 地址: TokenzQdBNb
前兩篇講了SPL Token與Account Model，現在要正式介紹token extension。
Token Extension Program（以下簡稱TEP） 原名 Token 2022，是一個基於原本Token Prgram（以下簡稱TP）的擴充版本。TEP被部署到的地
上一篇提到要在Solana上鑄造新的token需要使用到token program，功能較為陽春。隨著各種新需求的增加同時兼顧安全性的目的，一個新的token program - token 2022 （另名token extension）被開發出來，發佈在一個新的地址上。
Token 2022在
請新用戶參考新訂用戶須知並填寫Trading View個人帳號。對於續訂用戶，我們會延長您的權限，無需填寫問卷。請耐心等待通知。在等待權限開通的過程中，您可以先閱讀趨勢光譜列車區內的文章。若有任何個別問題，可發信cmoneyxiaop@gmail.com討論。
在串接第三方 API時，需要定期刷新 token，那有沒有辦法針對 request 和 response 做配置，在 token 過期時先做刷新、再做請求呢？本文要介紹利用 axios 套件提供的攔截器刷新 token 的作法。
為什麼要登出使用者？
安全性：防止未經授權的人，在使用者暫離時使用系統，這在公用或共享電腦的環境中尤其重要。
資料保護：只要使用者處於登入狀態，就會暴露在個人資料被他人操縱或利用的風險中，因此登出閒置使用者對資安也很重要。
如何在 Vue 3 專案中實作此功能？
當您在vCenter上發現Root使用者密碼過期的訊息時，該如何解決呢？本文將介紹如何透過SSH進入系統並立即變更密碼，以及如何將密碼設定成永不過期，避免再次遇到此問題。
前言
這篇文章分享cookie、sessionStorage、localStorage、session的差異，因為前後端溝通常用的就這幾個，我比較常用的是cookie或session，但也是有可能會用到sessionStorage或localStorage的時候，因此想說這邊做個紀錄比較他們的差別
權限管理=新增、修改、刪除+審核
通常，這種程式的設計會包含權限管理，其中包括現場修改、刪除等三大類功能。然而，根據經驗，我們還需要關注另一類功能，即審核權限。
審核不執行新增
審核權限通常不執行新增的動作，僅限於某些欄位的輸入。新增、修改、刪除這些操作基本上是容易理解的。也就是說，對於這個工
授權碼模式連線流程
用戶端請求自己的伺服器。
伺服器發現用戶沒登入，就導向認證伺服器。
認證伺服器顯示授權頁面，等待用戶授權。
用戶確認授權後，授權頁面會向認證伺服器請求授權碼。
用戶獲取授權碼。
用戶將授權碼傳給伺服器。
伺服器拿授權碼向認證伺服器取得token。
應用註冊