token給一個refuresh token，有個介面專門透過它來重新簽發token。

或者還剩指定時間的時候自動簽發token，客戶端判斷有就更新。

最極端可以每次訪問都重新簽發。

至於客戶端跟網頁的問題，可以透過某個欄位標識是什麼，簽發不同過期時間的token

每次給你簽發的token包含一個refresh token和一個access token，refresh token的超時時間比access token長，當發現access token超時之後，可以用refresh token去重新申請token簽發。refresh token只能用來重新申請token，不可用做正常的訪問控制。

這個問題有兩種處理策略：樂觀主義和悲觀主義。

樂觀主義顧名思義，認為客戶端在token過期之前肯定還會請求服務端，服務端判斷token出於更新視窗期了，於是對token進行更新。

悲觀主義認為這次客戶端與服務端的互動可能就是過期前的最後一次了，我要趁這次機會重新整理token，不然就超期失效了。

看下oauth2，用兩個token實現，個人覺得，jwt沒用，以前覺得jwt了，可以不用session或redis，實際情況不行，因為我們要對登入人的線上情況做控制，jwt了還要接redis，顯得多餘又麻煩，乾脆不用了，直接一個字串完事兒，後面接redis,想怎麼控制都可以。

使用者登入成功後，返回給客戶端兩個token：refresh token和access token。

前者失效時間短，用於呼叫重新整理token介面來獲取新的refresh token，來達到續期功能；後者失效時間長，當後者失效時，則需要使用者重新登入。

有一點要知道，jwt是一個協議，本身就是做stateless架構的，如果使用了Redis，其實和使用session並無區別，也就失去了jwt的特點，無狀態了。當然，如果需要踢出、多點登入管理等需求，確實要使用持久化儲存的，因為jwt一旦簽發，無法主動控制其失效，只能在服務端做判斷使其失效。

隨著技術的發展，分散式Web應用的普及，透過session管理使用者登入狀態成本越來越高，因此慢慢發展成為token的方式做登入身份校驗，然後透過token去取Redis中的快取的使用者資訊，隨著之後JWT的出現，校驗方式更加簡單便捷化，無需透過Redis快取，而是直接根據token取出儲存的使用者資訊，以及對token可用性校驗，單點登入更為簡單。

JWT中一般包含兩個token：access token和refresh token。當用戶透過登入等方式驗證身份成功後，伺服器會生成一個access token和一個refresh token，並返回到前端進行儲存。兩個token都會在伺服器設定過期時間，但access token的過期時間較短，而refresh token則較長。當前端向伺服器傳送請求時，access token隨著請求一起傳送到伺服器，用於驗證請求者的身份。當伺服器發現access token已經過期後，就會返回失敗資訊。此時前端需要使用refresh token向伺服器申請新的access token。如果refresh token沒有問題，伺服器就會生成新的access token返回。而如果refresh token也過期了，就需要再次向用戶要求登入驗證身份了。

總而言之，JWT延長時間是透過利用過期時間較長的refresh token重新申請新的access token實現的，而當refresh token也過期時，延長時間就不可能了。