1：傳統(tǒng)的session認(rèn)證

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

2：JWT

• 用戶通過(guò)賬號(hào)，密碼進(jìn)行登錄，獲得認(rèn)證
• 我們生成一個(gè)JWT返回給用戶，同時(shí)JWT也會(huì)進(jìn)行本地的保存
• 每次訪問(wèn)的時(shí)候，攜帶JWT，我們攔截器會(huì)對(duì)JWT進(jìn)行攔截
• 如果成功，就執(zhí)行響應(yīng)的業(yè)務(wù)邏輯處理
• 如果失敗，則返回錯(cuò)誤的信息

1：認(rèn)證的流程

• 賬號(hào)，密碼發(fā)送到后端的接口，http post請(qǐng)求
• 后端核對(duì)后，將用戶的ID和其他信息作為JWT payload，并且和頭部進(jìn)行base64的編碼后簽名，形成一個(gè)token。
• token： head，payload，簽名
• 后端將jwt字符串返回給前端，前端可以保存在緩存中，退出的手刪除
• 前端每次請(qǐng)求的時(shí)候?qū)WT放在header中的授權(quán)位
• 后端檢查是否存在，如果存在驗(yàn)證他的有效性，和時(shí)效性

2：結(jié)構(gòu)

• 表頭.payload.signature
• 標(biāo)頭：當(dāng)前的JWT類型和所使用的簽名 HS256
• 聲明：用戶和其他數(shù)據(jù)，同樣使用base64的編碼
  • 不要放比較敏感的信息
• 簽名：對(duì)前兩部分做加密，HS256，保證JWT沒(méi)有被篡改過(guò)

總結(jié)

以上是生活随笔為你收集整理的JWT 和 session验证的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。