SpringBoot項目要寫登錄注冊之類的方案
使用Cookie或Session的話，它是有狀態(tài)的，不符合分布式技術架構
使用Security或者Shiro框架實現(xiàn)起來比較復雜，一般項目無需用那么復雜
使用JWT它雖然是無狀態(tài)的，也可以載荷用戶數(shù)據(jù)，但還是有很多缺點:
- 缺點1：設置過期時間后，無法強制讓它過期，在有效期內它始終可用
- 缺點2：一次性的，如果用戶數(shù)據(jù)有變，只能重新生成新的JWT

以前登錄Token一般是放在服務端的Session中，Session有過期時間，也會自動延期，當然我們現(xiàn)在絕大部分項目都不會使用session來存儲了。

1、Redis+Token方案的授權流程

SpringBoot用普通的UUID作為token，返回到前端后，前端每次請求都會帶上這個token作為授權憑證。這種方案是能夠自動續(xù)簽，也能做到主動終止。所以很多項目用的都是Redis+Token方案，簡單方便問題少。缺點就是需要依賴Redis和數(shù)據(jù)庫。

流程 + lua優(yōu)化 ：

• 設置一個攔截器，不校驗登錄接口，攔截其他接口
• 登錄接口接收前端傳來的用戶名密碼，去數(shù)據(jù)庫查詢該用戶名是否存在，該密碼是否正確
• 如果正確則表示登錄成功，調用生成Token方法，返回Token給前端
• Token使用用戶id或賬號+時間戳+UUID用MD5加密的一串字符串（不建議用其他數(shù)據(jù)，因為id或賬號極少變更的，變更會增加復雜性）
• 生成后存儲到Redis，把Token當作鍵，用戶數(shù)據(jù)當作值，并設置過期時間
• 生成Token的方法中，還得防止重復調登錄接口，不停生成不同的Token，所以先判斷數(shù)據(jù)庫中是否存在鍵，所以保存token鍵到redis的同時要在redis中再增加一條用戶ID為鍵Token為值的數(shù)據(jù)，可以驗證該用戶是否已經生成過token

SpringBoot DEMO代碼：

接下來是校驗其他接口方法，同時也做了驗證和續(xù)期

2、JWT方案的的授權流程

2.1 JWT帶來的續(xù)簽和終止問題

JWT的優(yōu)勢在于無狀態(tài)，也就是生成的Token中本身有存儲信息，所以不需要依賴Redis和DB。JWT本身也有有效期參與簽名，問題在于這個有效期不能更改，也很好理解如果參與簽名的參數(shù)（有效期）發(fā)生變化，Token也就不一樣了。如果有效期不能改變，即便時間設計的再長，也會有到期的時候，而且Token這種設計初衷也不能有效期很長，導致用戶在操作過程中Token到期授權失敗，這種情況根本是無法接受的。

另外，JWT的Token簽發(fā)之后，理論上在到期之前是始終有效的，在有些場景下，比如用戶更改/重置密碼，踢出登錄（單一用戶登錄），都需要讓對應用戶在其他電腦（終端）上自動退出登錄，也就是要讓其他的Token馬上失效，所以需要額外設計來解決這兩個問題。

2.2 解決JWT自動續(xù)簽有幾個解決方案

• 每次請求都返回新的Token，這種簡單粗暴，不存在續(xù)簽的問題，不過相信很多人不會用，請求量大的話性能損耗也是比較明顯。
• 生成的JWT，不加入過期時間，在服務端Redis額外存儲一個對應的過期時間，并每次操作延期。這種設計感覺很多余，既然保存到了Redis，JWT從無狀態(tài)變成了有狀態(tài)，既然能夠保存過期時間，為啥不把用戶信息都保存到Redis中，何必用JWT加密后前后端傳來傳去沒有意義。
• 臨近過期刷新JWT，返回新的Token，很多人也采用的是這種方案。

2.3 解決JWT主動終止問題

• JWT簽發(fā)后就生效，無法做到主動終止，那還是用到Redis，把用戶id作為key，生成一個用戶唯一ID（用戶指紋）存入Redis，并參與JWT簽發(fā)過程；
• 如果更改了密碼需要終止其他所有已經簽發(fā)的JWT，只需要更改這個用戶指紋；
• 在JWT驗簽過程中，驗證用戶指紋，如果和JWT中信息不一致授權失敗，也就是做到了主動終止JWT的目的。
• 需要注意的是，在高并發(fā)過程中寫入用戶指紋過程可能要用到分布式鎖。

到此這篇關于SpringBoot中Token登錄授權、續(xù)期和主動終止的方案的文章就介紹到這了,更多相關SpringBoot Token登錄授權內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論