文章目錄
Sesstion
工作原理
Session 的優勢
- 相比 JWT ， 最大的優勢就在於可以主動清楚 session 了
- session 保存在服務器端，相對較爲安全
- 結合 cookie 使用， 較爲靈活， 兼容性較好
Session 的劣勢
- cookie + session 在跨域場景表現並不好
- 如果是分佈式部署，餘姚做多級共享 session 機制
- 基於 cookie 的機制很容易被
CSRF - 查詢 ·session· 信息可能會有數據庫查詢操作
Session 相關的概念介紹
- session： 主要存放在服務器端， 相對安全
- cookie： 主要存放在客戶端， 並且不是很安全
Session 相關的概念介紹
- sessionStorage ： 僅在當前會話下有效， 關閉頁面或者瀏覽器後被清楚
- localstorage: 除非別清楚， 否則永久保存
JWT
什麼是JWT？
- 定義了一種緊湊且獨立的方式嗎可以將各方之間的信息作爲JSON對象進行傳輸
- 該信息可以驗證和信任， 因爲是經過數字簽名的
header
- typ: token的類型， 這裏固定爲JWT
- alg: 使用過的 hash 算法， 例如： HMAC SHA256 或者 RSA
Payload
- 存儲需要傳遞的信息，如用戶ID、 用戶名等
- 還包含原數據、如果其時間、發佈人等
- 與Header不同， Payload 可以加密
Signature
- 對 Header 和 Payload 部分進行簽名
- 保證 Token 在傳輸的過程中沒有被篡改或者損壞
JWT vs Session
可拓展性
隨着應用程序的擴大，應用程序人員的增加， 必然要拓展我的程序， 有水平拓展， 垂直拓展， 水平拓展就是加服務器， 垂直拓展就是增加服務器的硬件性能， 比如： 磁盤、內存、cpu等。json數據是存在數據庫中的，在水平拓展方案中， 就需要獨立的、專門的、中心式的一個session存儲系統， 否則session是沒辦法共享的，存儲系統便於所有服務器都可以訪問session，共享session， 否則session的缺陷：存儲的缺陷無法得到水平拓展。在這種情況下JWT是比session好一些的。因爲session是無縫接入水平拓展的，基於token令牌這種校驗方式是無狀態的
安全性
-
XSS攻擊： 跨站腳本攻擊，JavaScript是可以修改JWT的， 因爲JWT是放在cookie sessionstorage中的。
防範: 簽名，加密 -
CSRF攻擊： 跟cookie相關，只要session或者JWT存在cookie中，就有可能出現跨站請求僞造
-
重放攻擊： 要儘量是過期時間短一些
-
中間人攻擊： 加了https就好了，在傳輸過程中是數據是加密的
-
RESTful API: rest架構應該是無狀態的， 所以session這種有狀態的認證方式， 顯然是不能用於RESTful API的
性能
- JWT的性能不太好，在客戶端發送服務端時， 可能會有大量的用戶信息在JWT中，那麼每個http請求都會產生大量的開銷， 如果是session值會有到少量的開銷， 因爲session的id非常的小，JWT應爲是個JSON，估計會是session的好幾倍，
- 但是session存在服務當中的，每次也要通過sessionID在數據庫中查看完整的信息，這肯定也是要消耗性能的
總的來說JWT就是用空間來換時間而session是用時間換空間性能方面各有利弊
時效性
JWT要比session差一些
- 原因： JWT只能等到過期時間進行銷燬， 而session存在服務端， 可以手動的去銷燬
- 場景1： 若JWT中存儲權限相關的信息，當前角色爲小管理員，應爲濫用管理員權限，就把當前角色權限降級了，但是JWT無法實時更新，必須等到過期才行，不能立即生效。所有當前角色可以乘着還是管理員的時間胡作非爲
- 場景2： 用戶發現自己的賬號在異地被登錄了，可能被盜號了。想修改密碼來防止盜號，但是JWT沒有過期，異地的賬號依然可以操作，包括修改密碼