shiro安全控制目錄

在構(gòu)建一個(gè)系統(tǒng)的時(shí)候，權(quán)限管理和用戶認(rèn)證是最基本的功能。而用戶認(rèn)證就是一個(gè)比較常見的模塊。在已有的方案中，我們最常見的就是保存到tomcat的session對象中，而隨著微服務(wù)的興起，一種新的認(rèn)證方式又火了起來，那就是JWT。

Sessionid和Token的區(qū)別

序 Session和Token的區(qū)別：

1. session出現(xiàn)的原因

因?yàn)閔ttp協(xié)議是無狀態(tài)的，所以服務(wù)端不能判斷本次請求和上次請求是不是同一個(gè)人操作的，故使用cookie和session來維護(hù)客戶狀態(tài)。

2. session生成的方式

瀏覽器在第一次訪問服務(wù)器時(shí)，服務(wù)器創(chuàng)建一個(gè)session，然后同時(shí)為該session生成一個(gè)唯一的會(huì)話sessionId，然后將sessionId和session存儲(chǔ)到Redis/內(nèi)存中，然后服務(wù)器再把sessionId（名字為JESSIONID的cookie），以cookie形式發(fā)送給客戶端。

瀏覽器再次訪問時(shí)會(huì)攜帶cookie中的sessionId，然后服務(wù)器根據(jù)sessionId找到對應(yīng)的session進(jìn)行匹配。如果瀏覽器禁用了cookie/不支持cookie，可以通過URL重寫的方式發(fā)送到服務(wù)器。

3. token出現(xiàn)的原因

session的存儲(chǔ)是需要空間的，session的傳輸一般都是通過cookie來傳輸，或url重寫的方式。而token在服務(wù)器時(shí)可以不存儲(chǔ)用戶信息的，token傳遞的方式也不限于cookie傳遞，token也可以保存起來。

4. token和session的區(qū)別

共同點(diǎn)：都是保存了用戶身份信息，都有過期時(shí)間。
session是會(huì)話，而token是令牌。
session是空間換時(shí)間，token是時(shí)間換空間。
session和sessionId：服務(wù)器會(huì)保存一份，可能保存到緩存/數(shù)據(jù)庫/文件。
token：服務(wù)器不需要記錄任何東西，每次都是一個(gè)無狀態(tài)的請求，每次都是通過解密算法來驗(yàn)證是否合法。
sessionId：一般是隨機(jī)字符串，要到服務(wù)器檢索id的有效性。

1. 兩種認(rèn)證方式的區(qū)別

當(dāng)一個(gè)設(shè)備（客戶端）向一個(gè)設(shè)備（服務(wù)端）發(fā)送請求的時(shí)候，服務(wù)端如何判斷這個(gè)客戶端是誰？傳統(tǒng)意義上的認(rèn)證方式又兩種：有狀態(tài)認(rèn)證、無狀態(tài)認(rèn)證。有狀態(tài)認(rèn)證和無狀態(tài)認(rèn)證最大的區(qū)別就是服務(wù)器會(huì)不會(huì)保存客戶端的信息。

2. 有狀態(tài)認(rèn)證

有狀態(tài)認(rèn)證，以cookie-session模型為例，當(dāng)客戶端第一次請求服務(wù)端的時(shí)候，服務(wù)端會(huì)返回客戶端一個(gè)唯一的標(biāo)識(shí)（默認(rèn)在cookie中），并保存對應(yīng)的客戶端信息，客戶端接受到唯一標(biāo)識(shí)之后，將標(biāo)識(shí)保存到本地cookie中，以后的每次請求都攜帶此cookie，服務(wù)器根據(jù)此cookie標(biāo)識(shí)就可以判斷請求的用戶是誰，然后查到對應(yīng)用戶的信息。

shiro的有狀態(tài)認(rèn)證邏輯圖.png

請求認(rèn)證過程（以tomcat為例）

1. 客戶端向服務(wù)器發(fā)送請求；
2. 第一次客戶端發(fā)起請求，服務(wù)器創(chuàng)建一個(gè)key為SESSIONID的值，并寫入到客戶端的cookie中，同時(shí)在服務(wù)器的Session Manager中創(chuàng)建一個(gè)對象，保存這個(gè)JESSIONID對應(yīng)的信息。
3. 以后客戶端每次請求，都會(huì)根據(jù)cookie進(jìn)行區(qū)別，我們可以通過session.setAttribute，session.getAttribute等方法擴(kuò)展用戶信息，根據(jù)用戶信息做一些業(yè)務(wù)判斷。
4. Session Manager中維護(hù)一個(gè)定時(shí)器，當(dāng)SESSIONID對應(yīng)的信息長時(shí)間沒有訪問（默認(rèn)30分鐘），或者顯式調(diào)用session.invalidate方法，那么這個(gè)對應(yīng)的信息就會(huì)被刪除。

SESSION認(rèn)證優(yōu)勢

因?yàn)榭蛻舳诵畔⒍急４嬖诜?wù)器的Session Manager中，如果將客戶端的認(rèn)證信息取消，只需要將Session中對應(yīng)信息刪除即可，及時(shí)相應(yīng)，方便快捷。

SESSION認(rèn)證劣勢

本質(zhì)上是以空間換時(shí)間。

1. 因?yàn)榉?wù)端保存著客戶端的信息，當(dāng)用戶量特別多時(shí)候，服務(wù)端需要特別的內(nèi)存資源；
2. 如果失效時(shí)間特別長的情況下，大量資源被占用無法釋放，如果釋放，那么相當(dāng)于用戶的注銷登錄；
3. 客戶端的信息在服務(wù)端中維護(hù)，如果服務(wù)端為集群的場景下，那么客戶端信息不共享，必須使用分布式 session 或者其他方案；
4. cookie有同源策略和跨域限制，部分業(yè)務(wù)場景下cookie并不能傳遞；
5. 部分設(shè)備本身不支持cookie或者禁用cookie，還有的手機(jī)瀏覽器也不支持cookie。

Shiro有狀態(tài)身份認(rèn)證——會(huì)話管理（整合Redis實(shí)現(xiàn)共享Session）

3. 無狀態(tài)認(rèn)證

無狀態(tài)的認(rèn)知，客戶端在提交身份信息，服務(wù)端驗(yàn)證身份后，根據(jù)一定的算法生成一個(gè)token令牌返回給客戶端，之后每次請求服務(wù)端，客戶端都需要攜帶此令牌，服務(wù)器接受到令牌之后進(jìn)行校驗(yàn)，校驗(yàn)通過后，提取令牌的信息用來區(qū)別用戶。

無狀態(tài)認(rèn)證.png

請求認(rèn)知過程

1. 執(zhí)行登錄操作，用戶端發(fā)送賬號(hào)密碼等信息。
2. 服務(wù)端校驗(yàn)賬號(hào)密碼是否正確，如果正確，根據(jù)對應(yīng)的用戶信息和服務(wù)端秘鑰生成JWT令牌，然后通過response.setHeader返回給客戶端（此處假設(shè)生成一個(gè)名為x-auth-token的令牌）。
3. 客戶端在返回成功之后，將Header中的x-auth-token保存到本地中。
4. 客戶端在以后每次請求服務(wù)器的時(shí)候，都會(huì)在header中攜帶x-auth-token令牌的值。
5. 服務(wù)端每接受到請求之后，判斷hader中是否包含x-auth-token，token 是否有效，然后通過 BASE 64 算法 decode，根據(jù)解密后的參數(shù)，判斷當(dāng)前 token 是否在有效期，所訪問的接口是否有權(quán)限等操作。

優(yōu)勢

1. 因?yàn)榉?wù)器不保留客戶端的任何信息，每次只需要通過特定的算法進(jìn)行校驗(yàn)，節(jié)省了大量的存儲(chǔ)空間。
2. 方便水平擴(kuò)容，不需要 SSO Server，只要保證新的應(yīng)用采用同樣的驗(yàn)證算法，就可以驗(yàn)證通過并獲得對應(yīng)信息。

劣勢

本質(zhì)上是以時(shí)間換空間
當(dāng)客戶端的token被盜用，或者需要手動(dòng)封禁某個(gè)用戶的時(shí)候，沒辦法對此token進(jìn)行操作，必須等待token失效（如果在服務(wù)端維護(hù)token和用戶的關(guān)系，技術(shù)可以實(shí)現(xiàn)，但是違背無狀態(tài)的設(shè)計(jì)理念）。

本文參考：

史亞健——淺析權(quán)限認(rèn)證中的有狀態(tài)和無狀態(tài)