前端認證登錄鑒權--Session 和 JWT簡介

Session 作業原理

當客戶端通過 username 和密碼請求服務端的時候,發出了一個 POST 請求.
服務端生成身份認證相關的 session 資料,比如查詢一下資料庫中該用戶名下有何其他資訊等, 生成一份 session 資料.

生成的 session 資料可能保存在記憶體里, 也可能保存在資料庫里,redis 里等等,并將 生成的 session-id回傳給客戶端. 通過 HTTP 一個回應頭 Set-Cookie: session = xxx把 session設定成session-id.
客戶端則把該 session-id 存在 cookie 中, 因為 Set-cookie 回應頭就是一個命令, 把它存在 cookie 中.

之后,所有的請求都附帶該 session-id, 比如發了一個 GET 請求,請求了 api/user, 請求里就帶了一個 cookie 頭, session = 剛才的 session-id
服務器接收到這個請求就會通過這個 session-id尋找session資料, 并決議 session 資料.
這樣就完成了登錄態. 如果通過校驗的話就正常走流程, 如果沒有就要重新登錄等等

客戶端手動清除 cookie 可以實作退出登錄, 后端如果希望強制前端重新登錄, 可以在服務端把 session 清除

**Tip: 注意區分上面的 session 和 session-id **

Session 的優勢

1.相比 JWT, session最大的優勢在于可以主動清除 session 了(因為 session 服務端有保存,所以可以主動清除). JWT 則是以 token 的形式保存在客戶端, 只要沒過期, 客戶端可以一直拿著 token 進行認證與授權
2. session 保存在服務器端, 相對較為安全(因為用戶可以輕易修改客戶端資料,比如 js 修改 cookie, 但是不容易通過嚴格安全規定的服務器端來修改)
3. 結合 cookie 使用, 比較靈活, 兼容性好

靈活: 客戶端和服務端都可以控制登錄態. 比如客戶端可以登出, 服務端也可以清楚 session.
或者說整個把 session 加密,把整個 session 保存在 cookie 里, 這樣不用把 session 保存在記憶體資料庫
兼容性: 指的大多數瀏覽器支持 session

Session 的劣勢

1. cookie + session 在跨域場景表現不好

因為 cookie 有不可跨域性. 設定 cookie 的時候不光設定 sessionid, 還有一個 domain 變數, 表示 cookie 生效的域名, 只有在這個域名下才生效. 因此跨域表現不好. 可以通過其他方式來進行跨域

2. 如果是分布式部署, 需要做多機共享 session 機制. session 多數情況下保存在記憶體里, 一臺服務器沒問題, 只要不重啟, 但是分布部署多服務器就要保證在多臺服務器共享和一致, 就增加了成本
3. 基于 cookie 的機制很容易被 CSRF(跨站請求偽造)

假如某用戶登陸過銀行網站,保存了 cookie, 如果點擊了釣魚連接, 有安全問題

4. 查詢 session 資訊可能會有資料庫查詢操作

保存在客戶端可能僅僅是 sessionid, 而完整 session 資訊保存在資料庫.

Session 相關概念

session: 主要放在服務器端, 相對安全
cookie: 主要放在客戶端, 并不是很安全
sessionStorage: 僅在當前會話下有效, 關閉頁面或者瀏覽器就清除掉了
localstorage: 在客戶端存盤變數的, 但是除非被清除, 否則永久保存(JWT 通常用 localstorage 來保存生成的 token)

什么是 JWT?

• JSON Web Token 是一個開放標準(詳細內容記錄在 RFC 7519 檔案中)
• 定義了一種緊湊且獨立的方式, 可以將各方資訊作為 JSON 物件進行安全傳輸
• 該資訊可以驗證和信任, 因為經過數字簽名的

JWT 的構成

1. 頭部( Header )

Header 本質是個 json, json 里面有兩個欄位
第一個欄位 typ: 代表 token 的型別, 這里固定為 JWT
第二個欄位 alg: 使用的 hash 演算法, 例如 HMAC SHA256 或者 RSA 等等

2. 有效載荷( payload )

存盤需要傳遞的資訊, 如用戶 id, 用戶名等等. 還包含元資料, 如過期時間,發布人等等
與 Header 不同, payload 可以加密

3. 簽名(signature)

對頭部和載荷部分簽名
保證 token 在傳輸程序中沒有被篡改或者損壞
為了加密多了一個秘鑰欄位

JWT 作業原理

瀏覽器端通過 POST 請求傳遞用戶名和密碼給服務端, 服務端校驗后, 如果成功將用戶 id 等其他資訊作為 jwt 的有效載荷和頭部進行 base64 編碼之后形成了一個 jwt, 這段 jwt 就像以點分割的亂碼字串.

然后后端將這個字串作為登錄成功的回傳結果和 200 狀態碼回傳給前端, 前端將其保存在 localstorage 和 sessionstorage 中, 每次請求都把這個 jwt 字串作為 http 頭里的 Authorization 加上 Bearer 和 jwt 字串, 發送給后端, 后端檢查是否存在和有效性(例如檢查簽名正確與否, 令牌過期與否等), 驗證通過后后端使用 jwt 中包含的用戶資訊, 這段用戶資訊保存在 jwt 的有效載荷中, 驗證解密后就拿到用戶資訊, 進行其他業務邏輯, 回傳結果

退出登錄的時候就洗掉這段 jwt字串就 ok

JWT vs. Session

• 可拓展性

隨著業務增加, 水平和縱向拓展增加必不可少. session 多以redis,資料庫等保存在服務器中, 水平拓展方案下需要創建一個獨立中心的存盤, 否則難以共享. 所以 jwt 要比 session 要好一點, 因為 jwt 可以無縫接入拓展, 因為基于token 令牌的驗證是無狀態的, 所以不需要在 session 中存盤用戶資訊, 可以使用 token 從不同服務器中訪問資源, 不用擔心用戶是否真的登錄到某臺服務器上, 不需要專門的 redis 等服務器來存盤, 僅是通過令牌來驗證. 節約成本. 應用程式方便拓展.

• 安全性

1. 對于XSS跨站腳本攻擊. js 可以修改 JWT, 因為 JWT 通常放在 localstorage 或 cookie 中, js 可以修改這些變數, 所以也可以修改 JWT, 此時就會出現 xss 攻擊, 比如壞人把代碼注入頁面中.
   如何防范呢?
   可以通過簽名, 加密兩種方式. 還有不要把敏感資訊放在 jwt 中, 防止密鑰泄露導致資訊泄露
2. 對于 CSRF, 不管是 jwt 還是 session 的 id, 都可能存在 cookie 里, 只要放 cookie 中, 就很容易受到 csrf. 因此不管是 jwt 還是 session, 都要確保必要的 csrf 保護
3. 對于重放攻擊, 要盡量jwt 和 session-id 的過期時間要盡量的短.
4. 對于中間人攻擊. 使用 https 可以防范,因為在傳輸期間也是加密的

• RESTful API 方面

RESTful 架構要求程式應該是無狀態的.因此 session 這種有狀態的認證方式, 顯然違反了 RESTful 的基本限制. 所以要用 jwt

• 性能

jwt 性能不太好.
因為在客戶端向服務端發出請求的時候, 可能有大量的用戶資訊在 jwt 中, 那么每個 http 請求都產生大量的開銷, 而 session 只用少量的開銷, 因為 session-id 比較小. jwt 是json, 而且包含了完整的資訊, 所以可能是它的好幾倍大. jwt 是空間換時間
而 session-id 的缺點是每一個請求都要在服務器上查找 session, 因為拿到的是 id, 沒有完整的資訊, 要用 id 查完整資訊. 所以要消耗性能. 而 jwt 完整資訊都在字串里, 不需要查詢

• 時效性

jwt 時效性差一些
因為 jwt 只有等到過期時間才可以銷毀, 而 session 可以在服務端主動銷毀.
如果 jwt 存盤權限相關資訊, 某賬號權限被降級, 但是因為 jwt 無法實時更新, 必須要等過期才行. 所以沒有辦法立即生效.
如果用戶發現賬號異地登錄, 但是由于 jwt 沒過期, 異地賬號依然可以操作包括修改密碼

Nodejs 中使用 jwt

安裝 jsonwebtoken
使用這個 npm 包提供的方法:
1. 對 json 物件進行簽名生成 token
  - jwt = require('jsonwebtoken');   
  - jwt.sign({name:'jack'},'mima')   //sign 方法第一個引數是一個 json 物件, 
//第二個引數是個密鑰
//然后生成一串兩個點分割的字串. 這就是 token, 可以把它傳到客戶端.以后客戶端的每個請求都
//拿著這個 token 傳給服務端. 

2. 逆向操作把 token 進行驗證
//然后服務端要進行驗證, 使用 verify 方法, 第二個引數是密鑰
jwt.verify(token, 'mima')

實作用戶注冊

• 再設計用戶 Schema

const userSchema = new Schema({
  name:{type: String, required: true},
  password:{type; String, require: true, select: false}
})
新加一個密碼規則, 并讓其默認在資料庫匯出不顯示

• 撰寫保證唯一性的邏輯

創建用戶的邏輯中添加邏輯

//獲取請求體中的用戶名, 用它進行查詢
const { name } = ctx.request.body;
//find 查詢出來的是個串列. 而查唯一需要用 findOne 方法
const repeatedUser = await User.findOne({name});
//然后判斷
if(repeatedUser) {
  ctx.throw(409,'用戶已存在');  //409代表沖突
}
//如果用手機,郵箱等判斷, 思路一致

實作登錄并獲取 Token

• 登錄介面設計

登錄介面不屬于增刪改查的一種,可以借鑒 github 設計, 動詞加

//先寫登錄的控制器,并注冊
 router.post('/login',login);
 
//實作介面
//做登錄首先要把用戶名和密碼傳進來,并校驗
async login(ctx) {
  ctx.verifyParams({
    name: {type:'string', required: true},
    password: {type:'string', require:true}
  })
}

 

• 用 jsonwebtoken 生成 token

//繼續往規則添加邏輯
async login(ctx) {
  ctx.verifyParams({
    name: {type:'string', required: true},
    password: {type:'string', require:true}
  })
  const user = await User.findOne(ctx.request.body);
  if(!user) {ctx.throw(401, '用戶名或密碼不正確');}
  // 拿到 user 以后拿出 id 和 name
  const {_id, name} = user;
  // 使用 jsonwebtoken 包提供的簽名方法,并設定過期時間
  const token = jsonwebtoken.sign({_id, name}, secret, {expiresIn: '1d'})
  // 把 token 放在 body 里
  ctx.body = {token}
}

現在就基本完成了登錄介面

手動撰寫 koa 中間件實作用戶認證與授權

• 認證: 驗證 token, 并獲取用戶資訊

這段代碼寫到中間件里. 因為避免重復代碼, 如果寫在每個介面控制器里會重復

// 一個中間件就是一個函式
const auth = async(ctx, next) => {
  // 認證其實就是決議 token,并從中獲取用戶資訊
  // 有很多種傳遞資料到服務端的方式,比如請求頭/請求體/路由引數/querystring, 
  // 在 jwt 認證方式里, 最標準的做法是把 token 放在請求頭里, 并且前面加 Bearer

  // 客戶端是通過請求頭的 authorization 欄位把 token 傳給服務端
  // 因此獲取 token 可以如下方式:
  const {authorization = ''} = ctx.request.header;
  // 去掉 Bearer 和空格
  const token = authorization.replace('Bearer','');

  try {
    // 通過 jsonwebtoken 包的方法驗證 token
    const user = jsonwebtoken.verify(token, secret);
    // 放置用戶資訊
    ctx.state.user = user
  } catch (err) {
    ctx.throw(401,err.message);
  }
  // 正常情況向下執行
  await next()
}

//把 auth 中間件添加到回應介面中, 比如
router.patch('/:id', auth, update)

以后登陸成功后才能請求這些介面

• 授權: 使用中間件保護介面

每個用戶權限不同

現在要完成授權功能, 也就是指定用戶能干什么

假設洗掉介面, 肯定只有自己能洗掉, 不能洗掉別人的賬號
所以要加授權邏輯
授權建立在認證基礎上, 先告訴服務器是誰, 再被授權

寫一個中間件檢查是否是自己, 把該控制器添加到回應介面
為了提升代碼復用性, 這個中間件單獨抽離出來


async checkOwner(ctx,next) {
  // 如果要修改的用戶 id !== 當前用戶id
  if(ctx.param.id !== ctx.state.user._id) {ctx.throw(403, '沒有權限')}
  await next();
}

//把 授權 中間件添加到回應介面中, 比如
router.patch('/:id', auth, checkOwner, update)

使用 koa-jwt 中間件實作用戶認證與授權

動態控制用戶資訊放哪, 函式動態生成密碼等更多功能

• 安裝 koa-jwt

npm i koa-jwt --save

• 使用中間件保護介面

//引入
const jwt = require('koa-jwt');
//一行搞定 auth 中間件
const auth = jwt({ secret })
//回應介面中添加
router.patch('/:id', auth, update)

• 使用中間件獲取用戶資訊

這個中間件用戶資訊也是在 state.user 里