在前后端分離架構中，用戶登錄成功后，后端頒發(fā)JWT token至前端，該token被安全存儲于LocalStorage。隨后，每次請求均自動攜帶此token于請求頭中，以驗證用戶身份。后端設有過濾器，攔截并校驗token有效性，一旦發(fā)現(xiàn)過期則引導用戶重新登錄。

簡單的說明token實現(xiàn)身份認證的步驟:

• 用戶登錄成功服務端返回token

• 之后每次用戶請求都攜帶token，在Authorization Header中。

• 后端服務取出token進行decode，判斷有效期及失效策略。

• 返回對應的成功失敗

鑒于JWT包含用戶信息且需保障安全，其過期時間通常設置較短。然而，這易導致用戶頻繁登錄，尤其是在處理復雜表單時(比如在線考試)，因耗時過長而遇token過期，引發(fā)不必要的登錄中斷和數(shù)據(jù)丟失，嚴重影響用戶體驗。如何在用戶無感知狀態(tài)下實現(xiàn)token自動續(xù)期的策略，減少頻繁登錄需求，確保表單數(shù)據(jù)不丟失?

解決token過期的續(xù)期問題可以有很多種不同的方案，這里舉一些比較有代表性的例子，一種是單token續(xù)期，一種是雙token續(xù)期。

1 單token續(xù)期

用戶認證與Token生成：用戶成功登錄后，服務端生成一個包含必要信息的JWT（Json Web Token），并返回給客戶端。此Token作為后續(xù)請求的身份驗證依據(jù)。

請求攜帶Token：在后續(xù)的每一次API請求中，客戶端都需在HTTP請求的Authorization頭部字段中攜帶此JWT，以便服務端驗證用戶的身份和權限。

Token管理策略：服務端設定了Token的失效時間（或失效次數(shù)）以及一個重新登錄的期限閾值。每當用戶登錄時，服務端會記錄當前的登錄時間，以便后續(xù)驗證使用。

Token驗證與響應：

• 當用戶攜帶Token發(fā)起請求時，服務端首先根據(jù)Token的失效時間和重新登錄期限進行驗證。
• 若Token有效，則正常處理請求并返回所需資源。
• 若Token已失效但仍在重新登錄期限內(nèi)，服務端返回特定的錯誤代碼提示Token已過期，同時提示客戶端進行Token刷新。

Token刷新機制：

• 客戶端接收到Token過期錯誤代碼后，自動調(diào)用Refresh Token接口，向服務端請求刷新Token。
• 服務端驗證請求的有效性（如檢查是否仍在重新登錄期限內(nèi)等），通過后生成新的有效Token并返回給客戶端。

使用刷新后的Token：客戶端在收到新的Token后，自動替換掉舊的Token，并在后續(xù)的請求中攜帶此新Token繼續(xù)訪問服務。

強制重新登錄：

• 若服務端判斷當前Token的使用時長已超過了設定的重新登錄期限，則不再允許通過Refresh Token接口刷新Token。
• 此時，服務端會返回強制重新登錄的錯誤代碼給客戶端，客戶端接收到此代碼后，應引導用戶跳轉至登錄頁面進行重新登錄。

比如:

• 將 token 過期時間設置為15分鐘；
• 前端發(fā)起請求，后端驗證 token 是否過期；如果過期，前端發(fā)起刷新token請求，后端為前端返回一個新的token；
• 前端用新的token發(fā)起請求，請求成功；
• 如果要實現(xiàn)每隔72小時，必須重新登錄，后端需要記錄每次用戶的登錄時間；用戶每次請求時，檢查用戶最后一次登錄日期，如超過72小時，則拒絕刷新token的請求，請求失敗，跳轉到登錄頁面。
• 后端還可以記錄刷新token的次數(shù)，比如最多刷新50次，如果達到50次，則不再允許刷新，需要用戶重新授權。

到此這篇關于SpringBoot中基于JWT的單token授權和續(xù)期方案的文章就介紹到這了,更多相關SpringBoot JWT token授權內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論