1.COOKIE使用和優缺點
1.1 cookie原理： 用戶名+密碼
- cookie是保存在用戶瀏覽器端，用戶名和密碼等明文信息
1.2 session使用原理
- session是存儲在服務器端的一段字符串,相當於字典的key
- 1.用戶向服務器發送用戶名和密碼。
- 2.驗證服務器后，相關數據（如用戶角色，登錄時間等）將保存在當前會話中。
- 3.服務器向用戶返回session_id，session信息都會寫入到用戶的Cookie。
- 4.用戶的每個后續請求都將通過在Cookie中取出session_id傳給服務器。
- 5.服務器收到session_id並對比之前保存的數據，確認用戶的身份。
1.3 session使用缺點
- 1.這種模式最大的問題是，沒有分布式架構，無法支持橫向擴展。
- 2.如果使用一個服務器，該模式完全沒有問題。
- 3.但是，如果它是服務器群集或面向服務的跨域體系結構的話，則需要一個統一的session數據庫庫 來保存會話數據實現共享，
- 4.這樣負載均衡下的每個服務器才可以正確的驗證用戶身份。
1.4 常用解決session方法
- 1.一種解決方案是通過持久化session數據，寫入數據庫或文件持久層等。
- 2.收到請求后，驗證服務從持久層請求數據。
- 3.依賴於持久層的數據庫或者問題系統，會有單點風險，如果持久層失敗，整個認證體系都會掛掉。
- 第一種：沒有session持久化
- 沒有分布式架構，無法支持橫向擴展
- session默認存儲在內存中，如果把代碼部署在多台機器上，session保存到了其中某一台機器 的內存中
- 用戶如果在A機器上登錄，只有A機器的內存中存了這個session的key，如果請求nginx路由到B 機器，B機器內存中沒有這個session數據，就需要從新登錄
- 第二種：寫入數據庫或文件持久層
- 解決了橫向擴展問題
- 數據庫持久層出現問題，所有集群都沒辦法登錄， 單點故障
- 如果數據放到mysql中，用戶量過大，查詢很慢，效率很低
2. JWT介紹
2.1 jwt原則
- 最簡單理解：jwt本質就是， 把用戶信息通過加密后生成的一個字符串
2.2 JWT的數據結構
- 1）jwt頭：JWT頭部分是一個描述JWT元數據的JSON對象
- 2）有效載荷：七個默認字段+自定義私有字段
- 3）簽名=HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload) ,secret)
第一部分： JWT頭
- base64UrlEncode(header) --->字符串
第二部分： 有效載荷 沒有敏感數據的用戶信息
- base64UrlEncode(payload) --->字符串
第三部分： 簽名哈希
- 簽名=HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload) ,secret)
2.3 jwt核心
- 1）給用戶頒發的token值相當於一把鎖，服務器端的秘鑰相當於一把鑰匙
- 2）每次客戶端請求都會攜帶這把鎖，服務器端用秘鑰去開這把鎖，若果無法打開就證明是偽造的
2.4 jwt特點分析
- 1、JWT的最大缺點是服務器不保存會話狀態，所以在使用期間不可能取消令牌或更改令牌的權 限，一旦JWT簽發，在有效期內將會一直有效。
- 2、JWT本身包含認證信息，因此一旦信息泄露，任何人都可以獲得令牌的所有權限。
- 3、為了減少盜用和竊取，JWT不建議使用HTTP協議來傳輸代碼，而是使用加密的HTTPS協議進行 傳輸。
- 4、JWT不僅可用於認證，還可用於信息交換，善用JWT有助於減少服務器請求數據庫的次數。