1：傳統的session認證

• http是一種無狀態的協議，每次都得我們用戶手動的去進行認證，根據http協議，我們并不知道當前的這一份請求是哪一個用戶發出的，所以我們能夠讓我們的應用能夠識別出來是哪一個用戶發起的請求，我們只能在服務器端存放一份用戶登錄的信息，這份登錄的信息在響應的時候會傳遞給瀏覽器，并且告訴他保存為cookie，以便下一次的請求的回收發送給我們的應用，這就是我們的session認證
• 缺點
  • 內存受到限制，session放在內存中，隨著用戶的增多，性能會收到限制
  • 記錄保存在內存中，在分布式的系統中，下一次的請求必須還要在這個服務器才能拿到資源，限制了負載均衡的能力
  • 基于cookie做識別的，如果cookie被篡改，很容易被攻擊
  • 在前后端分離的系統中
    • CSRF，跨站偽造請求攻擊，如果cookie被攔截，很容易被攻擊
    • 用戶的一次請求需要轉發多次，如果使用sessionID，每次都要查詢用戶的信息，給服務器增加負擔

2：JWT

• 用戶通過賬號，密碼進行登錄，獲得認證
• 我們生成一個JWT返回給用戶，同時JWT也會進行本地的保存
• 每次訪問的時候，攜帶JWT，我們攔截器會對JWT進行攔截
• 如果成功，就執行響應的業務邏輯處理
• 如果失敗，則返回錯誤的信息

1：認證的流程

• 賬號，密碼發送到后端的接口，http post請求
• 后端核對后，將用戶的ID和其他信息作為JWT payload，并且和頭部進行base64的編碼后簽名，形成一個token。
• token： head，payload，簽名
• 后端將jwt字符串返回給前端，前端可以保存在緩存中，退出的手刪除
• 前端每次請求的時候將JWT放在header中的授權位
• 后端檢查是否存在，如果存在驗證他的有效性，和時效性

2：結構

• 表頭.payload.signature
• 標頭：當前的JWT類型和所使用的簽名 HS256
• 聲明：用戶和其他數據，同樣使用base64的編碼
  • 不要放比較敏感的信息
• 簽名：對前兩部分做加密，HS256，保證JWT沒有被篡改過

總結

以上是生活随笔為你收集整理的JWT 和 session验证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。