常見的鑒權(quán)方式有兩種，一種是基于session，另一種是基于token方式的鑒權(quán)，我們來(lái)淺談一下兩種 鑒權(quán)方式的區(qū)別。
兩種鑒權(quán)方式對(duì)比
session
- 安全性：session是基于cookie進(jìn)行用戶識(shí)別的，cookie如果被截獲，用戶很容易受到跨站請(qǐng)求偽造的攻擊。
- 擴(kuò)展性：session是有狀態(tài)的，是具有IP黏貼性和有中心化特性的，在分布式環(huán)境下，雖然每臺(tái)服務(wù)器業(yè)務(wù)邏輯一樣，但是session是保存在各個(gè)服務(wù)器中的，而且每個(gè)服務(wù)器內(nèi)存是不共享的，如果使用session去實(shí)現(xiàn)分布式部署的話，需要使用其他的一些技術(shù)手段去實(shí)現(xiàn)，比如spring session，將session保存在第三方服務(wù)中，比如redis，這樣一旦第三方服務(wù)出現(xiàn)問(wèn)題，整個(gè)驗(yàn)權(quán)系統(tǒng)就會(huì)奔潰，在電商系統(tǒng)及高并發(fā)系統(tǒng)中的集群化處理顯然是不合適的。
- 抗壓能力：通常session是存儲(chǔ)在內(nèi)存中的，每個(gè)用戶通過(guò)認(rèn)證后都會(huì)將session存儲(chǔ)在服務(wù)器內(nèi)存中，當(dāng)用戶量增大的情況下服務(wù)器的壓力也隨之增大。
token
- 安全性：瀏覽器會(huì)將接收到的token值存儲(chǔ)在Local Storage中，（通過(guò)js代碼寫入Local Storage，通過(guò)js獲取，并不會(huì)像cookie一樣自動(dòng)攜帶）
- 擴(kuò)展性：token是無(wú)狀態(tài)的，是去中心化的，在分布式環(huán)境下，各個(gè)服務(wù)器中的服務(wù)只對(duì)token進(jìn)行數(shù)據(jù)查詢，它不需要在服務(wù)端保留用戶信息或者會(huì)話信息，這意味著用戶不需要考慮登錄的是哪一臺(tái)服務(wù)器，高效的解決了session擴(kuò)展性的弊端。
- 抗壓能力：token與session的不同主要在認(rèn)證成功后，會(huì)對(duì)當(dāng)前用戶數(shù)據(jù)進(jìn)行加密，生成一個(gè)加密字符串token，返還給客戶端（服務(wù)器端并不進(jìn)行保存）
基于token的鑒權(quán)方式
業(yè)界常用的授權(quán)標(biāo)準(zhǔn)有兩種，一種是使用auth2，這種方式更適合于類似第三方授權(quán)登錄，比如微信、微博、QQ信任登錄業(yè)務(wù)。另一種是oauth，即第三方無(wú)需知道用戶和密碼就可以申請(qǐng)獲得該資源的授權(quán)，更適用于對(duì)用戶的權(quán)限校驗(yàn)并分配訪問(wèn)權(quán)限，比如常見的登錄后分配可見資源（按鈕、菜單等）類型網(wǎng)站。
JAVAshop電商系統(tǒng) 采用的是oauth方式的鑒權(quán)標(biāo)準(zhǔn)。我們以系統(tǒng)的應(yīng)用為例來(lái)介紹oauth的方案。
1. 登錄
服務(wù)端校驗(yàn)密碼，成功后返回access_token和refresh_token，客戶端記錄上述token。
2. 訪問(wèn)API
在訪問(wèn)API之前解析access_token，并且查看是否過(guò)期，如果不過(guò) 期則請(qǐng)求API，如果過(guò)期，則要刷新令牌，在請(qǐng)求API。
3. 刷新token
攜帶有效期的refresh_token換回有效token，如果refresh_token過(guò)期，則需要用戶重新登錄。
4. 注銷
請(qǐng)求注銷api，服務(wù)器端和客戶端應(yīng)同時(shí)刪除token的存儲(chǔ)。
1. 客戶端請(qǐng)求API
攜帶access_token信息，如果生成環(huán)境不會(huì)直接攜帶access_token，會(huì)使用加密后的簽名校驗(yàn)。祥見以下防重放機(jī)制。
2. 獲取token
根據(jù)環(huán)境不同而有不同的獲取token方式。
3. 解析token
通過(guò)JWT工具將token解析。
4. 由redis讀取token
根據(jù)uid拼接key讀取access_token, 如果不存在這個(gè)用戶的token說(shuō)明已經(jīng)登出。
5. 驗(yàn)證token
判斷次token是否屬于此uid，判斷token是否過(guò)期，如果過(guò)期則進(jìn)行以下刷新token的流程。
6. 注入權(quán)限
如果token驗(yàn)證成功，根據(jù)user信息生成權(quán)限注入到spring安全上下文中。
刷新token流程
1. 客戶端請(qǐng)求API
攜帶refresh_token，如果是生產(chǎn)環(huán)境不會(huì)直接攜帶refresh_token信息，詳見以下防重放攻擊。
2. 獲取token
根據(jù)環(huán)境不同而有不同的獲取token方式。
3. 解析token
通過(guò)JWT工具將token解析。
4. token讀取
根據(jù)uid拼接key讀取出access_token，如果不存在這個(gè)用戶的token說(shuō)明用戶已經(jīng)登出。
5. 驗(yàn)證token
判斷此token是否屬于此uid，判斷token是否已經(jīng)過(guò)期，如果過(guò)期，則返回refresh_token過(guò)期錯(cuò)誤，此時(shí)用戶需要重新登錄。
6. 刷新token
如果refresh_token 驗(yàn)證成功，則重新生成access_token和refresh_token，上述有效期以當(dāng)前時(shí)間向后計(jì)算，替換此用戶在redis中的token，并將token返回給客戶端。
防重放機(jī)制
一、 參數(shù)的讀取
1. 在生產(chǎn)環(huán)境時(shí)，不能直接傳遞token,而是要傳遞簽名數(shù)據(jù)，服務(wù)器端驗(yàn)簽后由Redis中獲取簽名。
2. 如果是非生產(chǎn)環(huán)境，直接由header中讀取token。
二、 生產(chǎn)環(huán)境傳遞如下參數(shù)
memberid (用戶id)
nonce（隨機(jī)字串，6位）
timestamp(當(dāng)前時(shí)間戳，到秒)
sign= md5( uid+ nonce + timestamp +token )
三、 驗(yàn)證邏輯
1. 驗(yàn)證時(shí)間戳
判斷時(shí)間戳是否起過(guò)60s，大于60s則判別為重放功擊。
2. 驗(yàn)證nonce
首先驗(yàn)證nonce在 reids中是否存在，如果存在，則判別為重放功擊，否則將nonce記錄在redis中（key為："nonce"+uid+"_"+nonce），失效時(shí)間為60s。
3. 驗(yàn)證sign
md5( uid+ nonce + timestamp +token ) 驗(yàn)證是簽名是否通過(guò)。
4. 驗(yàn)證token
通過(guò)uid拿到token ，驗(yàn)證邏輯同驗(yàn)權(quán)流程。
當(dāng)然在不同的業(yè)務(wù)場(chǎng)景下實(shí)現(xiàn)方案是多種多樣的，僅以此方案拋轉(zhuǎn)引玉，供大家參考。
