session共享

什么是session共享

????????Session共享是指在分布式系統(tǒng)中，在多個(gè)服務(wù)器之間共享同一個(gè)用戶的會(huì)話數(shù)據(jù)。在傳統(tǒng)的Web應(yīng)用中，用戶的會(huì)話信息通常存儲(chǔ)在服務(wù)器端的Session中，而每個(gè)用戶的請(qǐng)求在同一個(gè)服務(wù)器上處理，因此可以輕松地訪問和管理會(huì)話信息。

為什么要使用session共享

????????在分布式系統(tǒng)中，用戶的請(qǐng)求可能會(huì)被不同的服務(wù)器處理，這就導(dǎo)致了會(huì)話信息無(wú)法簡(jiǎn)單地在不同服務(wù)器之間共享的問題

解決方案：

1. Session復(fù)制：

   • 當(dāng)一個(gè)服務(wù)器上的會(huì)話發(fā)生變化時(shí)，這些變化會(huì)被復(fù)制到其他所有服務(wù)器上。
   • 這意味著每個(gè)服務(wù)器都有會(huì)話數(shù)據(jù)的完整副本。
   • 但這種方法可能會(huì)導(dǎo)致性能問題和數(shù)據(jù)同步問題。

2. Session中心化存儲(chǔ)：

   • 將會(huì)話數(shù)據(jù)存儲(chǔ)在中央數(shù)據(jù)庫(kù)或緩存系統(tǒng)中，如JWT或Redis。
   • 當(dāng)用戶訪問任何服務(wù)器時(shí)，該服務(wù)器都會(huì)從中央存儲(chǔ)中檢索會(huì)話數(shù)據(jù)。
   • 這種方法可以確保數(shù)據(jù)的一致性和可伸縮性。

3. 使用Cookie：

   • 將會(huì)話標(biāo)識(shí)符存儲(chǔ)在用戶的瀏覽器中作為Cookie。
   • 當(dāng)用戶訪問其他服務(wù)器時(shí)，他們會(huì)帶上這個(gè)Cookie，服務(wù)器可以從這個(gè)標(biāo)識(shí)符中檢索會(huì)話數(shù)據(jù)。
   • 這種方法簡(jiǎn)單，但依賴于用戶的瀏覽器和Cookie的安全性。

4. 粘性會(huì)話：

   • 使用負(fù)載均衡器確保一旦用戶被分配到一個(gè)服務(wù)器，他們后續(xù)的所有請(qǐng)求都被路由到該服務(wù)器。
   • 這確保了會(huì)話數(shù)據(jù)只存在于一個(gè)服務(wù)器上，從而避免了共享的需求。
   • 但這種方法限制了服務(wù)器的可伸縮性。

5. 分布式會(huì)話管理：

   • 使用專門的會(huì)話管理系統(tǒng)或服務(wù)來(lái)管理會(huì)話數(shù)據(jù)。
   • 這些系統(tǒng)通常提供高可用性、可擴(kuò)展性和安全性。

Session中心化存儲(chǔ)（JWT）介紹

什么是JWT（JSON Web Token）

在介紹JWT之前，我們先來(lái)回顧一下利用token進(jìn)行用戶身份驗(yàn)證的流程：

1. 客戶端使用用戶名和密碼請(qǐng)求登錄
2. 服務(wù)端收到請(qǐng)求，驗(yàn)證用戶名和密碼
3. 驗(yàn)證成功后，服務(wù)端會(huì)簽發(fā)一個(gè)token，再把這個(gè)token返回給客戶端
4. 客戶端收到token后可以把它存儲(chǔ)起來(lái)，比如放到cookie中
5. 客戶端每次向服務(wù)端請(qǐng)求資源時(shí)需要攜帶服務(wù)端簽發(fā)的token，可以在cookie或者h(yuǎn)eader中攜帶
6. 服務(wù)端收到請(qǐng)求，然后去驗(yàn)證客戶端請(qǐng)求里面帶著的token，如果驗(yàn)證成功，就向客戶端返回請(qǐng)求數(shù)據(jù)

詳細(xì)過程：

• 前端發(fā)送登錄請(qǐng)求：用戶在前端頁(yè)面輸入用戶名和密碼后，前端將這些憑證發(fā)送到后端的登錄接口。
• 后端驗(yàn)證用戶信息：后端接收到登錄請(qǐng)求后，首先驗(yàn)證用戶提供的用戶名和密碼是否正確。如果驗(yàn)證通過，后端生成一個(gè)Token，并將Token與用戶信息關(guān)聯(lián)起來(lái)。
• 后端生成Token：后端使用一種安全的算法（如JWT）生成一個(gè)Token，Token中包含用戶的身份信息和其他必要的信息。Token可以包含用戶ID、角色、過期時(shí)間等。
• 后端返回Token給前端：后端將生成的Token作為響應(yīng)返回給前端。前端可以將Token保存在本地，通常使用瀏覽器的Cookie或本地存儲(chǔ)（如localStorage）來(lái)保存Token。
• 前端發(fā)送請(qǐng)求時(shí)攜帶Token：在后續(xù)的請(qǐng)求中，前端需要在請(qǐng)求的頭部（通常是Authorization頭）中攜帶Token。這可以通過在每個(gè)請(qǐng)求的頭部中添加"Authorization: Bearer {Token}"來(lái)實(shí)現(xiàn)。
• 后端驗(yàn)證Token：后端在接收到請(qǐng)求時(shí)，會(huì)從請(qǐng)求頭部中獲取Token，并進(jìn)行驗(yàn)證。驗(yàn)證包括檢查Token的有效性、過期時(shí)間以及用戶的權(quán)限等。如果Token驗(yàn)證通過，后端會(huì)處理請(qǐng)求并返回相應(yīng)的數(shù)據(jù)。
• Token的刷新和注銷：在一些情況下，Token可能會(huì)過期或需要刷新。前端可以通過發(fā)送刷新Token的請(qǐng)求來(lái)獲取新的Token，并更新本地保存的Token。另外，用戶也可以選擇注銷登錄，前端可以清除本地保存的Token。

這種基于token的認(rèn)證方式相比傳統(tǒng)的session認(rèn)證方式更節(jié)約服務(wù)器資源，并且對(duì)移動(dòng)端和分布式更加友好。其優(yōu)點(diǎn)如下：

1. 支持跨域訪問：cookie是無(wú)法跨域的，而token由于沒有用到cookie(前提是將token放到請(qǐng)求頭中)，所以跨域后不會(huì)存在信息丟失問題
2. 無(wú)狀態(tài)：token機(jī)制在服務(wù)端不需要存儲(chǔ)session信息，因?yàn)閠oken自身包含了所有登錄用戶的信息，所以可以減輕服務(wù)端壓力
3. 更適用CDN：可以通過內(nèi)容分發(fā)網(wǎng)絡(luò)請(qǐng)求服務(wù)端的所有資料
4. 更適用于移動(dòng)端：當(dāng)客戶端是非瀏覽器平臺(tái)時(shí)，cookie是不被支持的，此時(shí)采用token認(rèn)證方式會(huì)簡(jiǎn)單很多
5. 無(wú)需考慮CSRF：由于不再依賴cookie，所以采用token認(rèn)證方式不會(huì)發(fā)生CSRF，所以也就無(wú)需考慮CSRF的防御

而JWT就是上述流程當(dāng)中token的一種具體實(shí)現(xiàn)方式，其全稱是JSON Web Token，

官網(wǎng)地址：JSON Web Tokens - jwt.io

????????通俗地說，JWT的本質(zhì)就是一個(gè)字符串，它是將用戶信息保存到一個(gè)Json字符串中，然后進(jìn)行編碼后得到一個(gè)JWT token，并且這個(gè)JWT token帶有簽名信息，接收后可以校驗(yàn)是否被篡改，所以可以用于在各方之間安全地將信息作為Json對(duì)象傳輸。JWT的認(rèn)證流程如下：

1. ????????首先，前端通過Web表單將自己的用戶名和密碼發(fā)送到后端的接口，這個(gè)過程一般是一個(gè)POST請(qǐng)求。建議的方式是通過SSL加密的傳輸(HTTPS)，從而避免敏感信息被嗅探
2. 后端核對(duì)用戶名和密碼成功后，將包含用戶信息的數(shù)據(jù)作為JWT的Payload，將其與JWT Header分別進(jìn)行Base64編碼拼接后簽名，形成一個(gè)JWT Token，形成的JWT Token就是一個(gè)如同lll.zzz.xxx的字符串
3. ????????后端將JWT Token字符串作為登錄成功的結(jié)果返回給前端。前端可以將返回的結(jié)果保存在瀏覽器中，退出登錄時(shí)刪除保存的JWT Token即可
4. ????????前端在每次請(qǐng)求時(shí)將JWT Token放入HTTP請(qǐng)求頭中的Authorization屬性中(解決XSS和XSRF問題)
5. ????????后端檢查前端傳過來(lái)的JWT Token，驗(yàn)證其有效性，比如檢查簽名是否正確、是否過期、token的接收方是否是自己等等
6. ????????驗(yàn)證通過后，后端解析出JWT Token中包含的用戶信息，進(jìn)行其他邏輯操作(一般是根據(jù)用戶信息得到權(quán)限等)，返回結(jié)果

為什么要用JWT

傳統(tǒng)Session認(rèn)證的弊端

????????我們知道HTTP本身是一種無(wú)狀態(tài)的協(xié)議，這就意味著如果用戶向我們的應(yīng)用提供了用戶名和密碼來(lái)進(jìn)行用戶認(rèn)證，認(rèn)證通過后HTTP協(xié)議不會(huì)記錄下認(rèn)證后的狀態(tài)，那么下一次請(qǐng)求時(shí)，用戶還要再一次進(jìn)行認(rèn)證，因?yàn)楦鶕?jù)HTTP協(xié)議，我們并不知道是哪個(gè)用戶發(fā)出的請(qǐng)求，所以為了讓我們的應(yīng)用能識(shí)別是哪個(gè)用戶發(fā)出的請(qǐng)求，我們只能在用戶首次登錄成功后，在服務(wù)器存儲(chǔ)一份用戶登錄的信息，這份登錄信息會(huì)在響應(yīng)時(shí)傳遞給瀏覽器，告訴其保存為cookie，以便下次請(qǐng)求時(shí)發(fā)送給我們的應(yīng)用，這樣我們的應(yīng)用就能識(shí)別請(qǐng)求來(lái)自哪個(gè)用戶了，這是傳統(tǒng)的基于session認(rèn)證的過程

然而，傳統(tǒng)的session認(rèn)證有如下的問題：

1. 每個(gè)用戶的登錄信息都會(huì)保存到服務(wù)器的session中，隨著用戶的增多，服務(wù)器開銷會(huì)明顯增大
2. 由于session是存在與服務(wù)器的物理內(nèi)存中，所以在分布式系統(tǒng)中，這種方式將會(huì)失效。雖然可以將session統(tǒng)一保存到Redis中，但是這樣做無(wú)疑增加了系統(tǒng)的復(fù)雜性，對(duì)于不需要redis的應(yīng)用也會(huì)白白多引入一個(gè)緩存中間件
3. 對(duì)于非瀏覽器的客戶端、手機(jī)移動(dòng)端等不適用，因?yàn)閟ession依賴于cookie，而移動(dòng)端經(jīng)常沒有cookie
4. 因?yàn)閟ession認(rèn)證本質(zhì)基于cookie，所以如果cookie被截獲，用戶很容易收到跨站請(qǐng)求偽造攻擊。并且如果瀏覽器禁用了cookie，這種方式也會(huì)失效
5. 前后端分離系統(tǒng)中更加不適用，后端部署復(fù)雜，前端發(fā)送的請(qǐng)求往往經(jīng)過多個(gè)中間件到達(dá)后端，cookie中關(guān)于session的信息會(huì)轉(zhuǎn)發(fā)多次
6. 由于基于Cookie，而cookie無(wú)法跨域，所以session的認(rèn)證也無(wú)法跨域，對(duì)單點(diǎn)登錄不適用

JWT認(rèn)證的優(yōu)勢(shì)

對(duì)比傳統(tǒng)的session認(rèn)證方式，JWT的優(yōu)勢(shì)是：

1. 簡(jiǎn)潔：JWT Token數(shù)據(jù)量小，傳輸速度也很快
2. 因?yàn)镴WT Token是以JSON加密形式保存在客戶端的，所以JWT是跨語(yǔ)言的，原則上任何web形式都支持
3. 不需要在服務(wù)端保存會(huì)話信息，也就是說不依賴于cookie和session，所以沒有了傳統(tǒng)session認(rèn)證的弊端，特別適用于分布式微服務(wù)
4. 單點(diǎn)登錄友好：使用Session進(jìn)行身份認(rèn)證的話，由于cookie無(wú)法跨域，難以實(shí)現(xiàn)單點(diǎn)登錄。但是，使用token進(jìn)行認(rèn)證的話， token可以被保存在客戶端的任意位置的內(nèi)存中，不一定是cookie，所以不依賴cookie，不會(huì)存在這些問題
5. 適合移動(dòng)端應(yīng)用：使用Session進(jìn)行身份認(rèn)證的話，需要保存一份信息在服務(wù)器端，而且這種方式會(huì)依賴到Cookie（需要 Cookie 保存 SessionId），所以不適合移動(dòng)端

JWT結(jié)構(gòu)

JWT由3部分組成：標(biāo)頭(Header)、有效載荷(Payload)和簽名(Signature)。在傳輸?shù)臅r(shí)候，會(huì)將JWT的3部分分別進(jìn)行Base64編碼后用.進(jìn)行連接形成最終傳輸?shù)淖址?/p>

JWTString=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)

1.Header
JWT頭是一個(gè)描述JWT元數(shù)據(jù)的JSON對(duì)象，alg屬性表示簽名使用的算法，默認(rèn)為HMAC SHA256（寫為HS256）；typ屬性表示令牌的類型，JWT令牌統(tǒng)一寫為JWT。最后，使用Base64 URL算法將上述JSON對(duì)象轉(zhuǎn)換為字符串保存

{"alg": "HS256","typ": "JWT"
}

2.Payload
有效載荷部分，是JWT的主體內(nèi)容部分，也是一個(gè)JSON對(duì)象，包含需要傳遞的數(shù)據(jù)。 JWT指定七個(gè)默認(rèn)字段供選擇

iss：發(fā)行人
exp：到期時(shí)間
sub：主題
aud：用戶
nbf：在此之前不可用
iat：發(fā)布時(shí)間
jti：JWT ID用于標(biāo)識(shí)該JWT

這些預(yù)定義的字段并不要求強(qiáng)制使用。除以上默認(rèn)字段外，我們還可以自定義私有字段，一般會(huì)把包含用戶信息的數(shù)據(jù)放到payload中，如下例：

{"sub": "1234567890","name": "Helen","admin": true
}

請(qǐng)注意，默認(rèn)情況下JWT是未加密的，因?yàn)橹皇遣捎胋ase64算法，拿到JWT字符串后可以轉(zhuǎn)換回原本的JSON數(shù)據(jù)，任何人都可以解讀其內(nèi)容，因此不要構(gòu)建隱私信息字段，比如用戶的密碼一定不能保存到JWT中，以防止信息泄露。JWT只是適合在網(wǎng)絡(luò)中傳輸一些非敏感的信息

3.Signature
簽名哈希部分是對(duì)上面兩部分?jǐn)?shù)據(jù)簽名，需要使用base64編碼后的header和payload數(shù)據(jù)，通過指定的算法生成哈希，以確保數(shù)據(jù)不會(huì)被篡改。首先，需要指定一個(gè)密鑰（secret）。該密碼僅僅為保存在服務(wù)器中，并且不能向用戶公開。然后，使用header中指定的簽名算法（默認(rèn)情況下為HMAC SHA256）根據(jù)以下公式生成簽名
H M A C S H A 256 ( b a s e 64 U r l E n c o d e ( h e a d e r ) + " . " + b a s e 64 U r l E n c o d e ( p a y l o a d ) , s e c r e t ) HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)

在計(jì)算出簽名哈希后，JWT頭，有效載荷和簽名哈希的三個(gè)部分組合成一個(gè)字符串，每個(gè)部分用.分隔，就構(gòu)成整個(gè)JWT對(duì)象

注意JWT每部分的作用，在服務(wù)端接收到客戶端發(fā)送過來(lái)的JWT token之后：

header和payload可以直接利用base64解碼出原文，從header中獲取哈希簽名的算法，從payload中獲取有效數(shù)據(jù)
signature由于使用了不可逆的加密算法，無(wú)法解碼出原文，它的作用是校驗(yàn)token有沒有被篡改。服務(wù)端獲取header中的加密算法之后，利用該算法加上secretKey對(duì)header、payload進(jìn)行加密，比對(duì)加密后的數(shù)據(jù)和客戶端發(fā)送過來(lái)的是否一致。注意secretKey只能保存在服務(wù)端，而且對(duì)于不同的加密算法其含義有所不同，一般對(duì)于MD5類型的摘要加密算法，secretKey實(shí)際上代表的是鹽值