1.COOKIE使用和優(yōu)缺點(diǎn)

1.1cookie原理：用戶名 密碼

• cookie是保存在用戶瀏覽器端，用戶名和密碼等明文信息

1.2 session使用原理

• session是存儲(chǔ)在服務(wù)器端的一段字符串,相當(dāng)于字典的key

• 1.用戶向服務(wù)器發(fā)送用戶名和密碼。
• 2.驗(yàn)證服務(wù)器后，相關(guān)數(shù)據(jù)（如用戶角色，登錄時(shí)間等）將保存在當(dāng)前會(huì)話中。
• 3.服務(wù)器向用戶返回session_id，session信息都會(huì)寫入到用戶的Cookie。
• 4.用戶的每個(gè)后續(xù)請(qǐng)求都將通過在Cookie中取出session_id傳給服務(wù)器。
• 5.服務(wù)器收到session_id并對(duì)比之前保存的數(shù)據(jù)，確認(rèn)用戶的身份

1.3 session使用缺點(diǎn)

• 1.這種模式最大的問題是，沒有分布式架構(gòu)，無法支持橫向擴(kuò)展。
• 2.如果使用一個(gè)服務(wù)器，該模式完全沒有問題。
• 3.但是，如果它是服務(wù)器群集或面向服務(wù)的跨域體系結(jié)構(gòu)的話，則需要一個(gè)統(tǒng)一的session數(shù)據(jù)庫庫
• 來保存會(huì)話數(shù)據(jù)實(shí)現(xiàn)共享，
• 4.這樣負(fù)載均衡下的每個(gè)服務(wù)器才可以正確的驗(yàn)證用戶身份。

1.4 常用解決session方法

• 1.一種解決方式是通過持久化session數(shù)據(jù)，寫入數(shù)據(jù)庫或文件持久層等。

• 2.收到請(qǐng)求后，驗(yàn)證服務(wù)從持久層請(qǐng)求數(shù)據(jù)

• 3.依賴于持久層的數(shù)據(jù)庫或者問題系統(tǒng)，會(huì)有單點(diǎn)風(fēng)險(xiǎn) ，如果持久層失敗，整個(gè)認(rèn)證體系都會(huì)垮掉

• 第一種：沒有session持久化

  • 沒有分布式架構(gòu)，無法支持橫向擴(kuò)展
  • session默認(rèn)存儲(chǔ)在內(nèi)存中，如果把代碼部署在多臺(tái)機(jī)器上，session保存到了其中某一臺(tái)機(jī)器的內(nèi)存中
  • 用戶如果在A機(jī)器上登錄，只有A機(jī)器的內(nèi)存中存了這個(gè)session的key，如果請(qǐng)求nginx路由到B機(jī)器，B機(jī)器內(nèi)存中沒有這個(gè)session數(shù)據(jù)，就需要從新登錄

• 第二種：寫入數(shù)據(jù)庫或文件持久層

  • 解決了橫向擴(kuò)展問題
  • 數(shù)據(jù)庫持久層出現(xiàn)問題，所有集群都沒辦法登錄， 單點(diǎn)故障
  • 如果數(shù)據(jù)放到mysql中，用戶量過大，查詢很慢，效率很低

2. JWT介紹

2.1 jwt原則

• 最簡單理解：jwt本質(zhì)就是， 把用戶信息通過加密后生成的一個(gè)字符串

JWT的原則是在服務(wù)器身份驗(yàn)證之后，將生成一個(gè)JSON對(duì)象并將其發(fā)送回用戶
{
  "UserName": "Chongchong",
   "Role": "Admin",
   "Expire": "2018-08-08 20:15:56"
}
之后，當(dāng)用戶與服務(wù)器通信時(shí)，客戶在請(qǐng)求中發(fā)回JSON對(duì)象，服務(wù)器僅依賴于這個(gè)JSON對(duì)象來標(biāo)識(shí)用戶。 為了防止用戶篡改數(shù)據(jù)，服務(wù)器將在生成對(duì)象時(shí)添加簽名（有關(guān)詳細(xì)信息，請(qǐng)參閱下文）。 服務(wù)器不保存任何會(huì)話數(shù)據(jù)，即服務(wù)器變?yōu)闊o狀態(tài)，使其更容易擴(kuò)展

2.2 JWT的數(shù)據(jù)結(jié)構(gòu)

• 1. jwt頭：JWT頭部分是一個(gè)描述JWT元數(shù)據(jù)的JSON對(duì)象

• 2）有效載荷：七個(gè)默認(rèn)字段 自定義私有字段

• 3）簽名=HMACSHA256(base64UrlEncode(header) "." base64UrlEncode(payload),secret)

第一部分 ：JWT頭

• base64UrlEncode(header)—>字符串

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

第二部分： 有效載荷 沒有敏感數(shù)據(jù)的用戶信息

base64UrlEncode(payload)—>字符串

#1、有效載荷部分，是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
'''

#2、除以上默認(rèn)字段外，我們還可以自定義私有字段，如下例：
{
"sub": "1234567890",
"name": "chongchong",
"admin": true
}
#3、注意 默認(rèn)情況下JWT是未加密的，任何人都可以解讀其內(nèi)容，因此不要構(gòu)建隱私信息字段，存放保密信息，以防 止信息泄露。
JSON對(duì)象也使用Base64 URL算法轉(zhuǎn)換為字符串保存

第三部分： 簽名哈希

• 簽名=HMACSHA256(base64UrlEncode(header) "." base64UrlEncode(payload),secret)

  # 1.簽名哈希部分是對(duì)上面兩部分?jǐn)?shù)據(jù)簽名，通過指定的算法生成哈希，以確保數(shù)據(jù)不會(huì)被篡改。
  # 2.首先，需要指定一個(gè)密碼（secret），該密碼僅僅為保存在服務(wù)器中，并且不能向用戶公開。
  # 3.然后，使用標(biāo)頭中指定的簽名算法（默認(rèn)情況下為HMAC SHA256）根據(jù)以下公式生成簽名。
  # 4.HMACSHA256(base64UrlEncode(header)   "."   base64UrlEncode(payload),secret)
  # 5.在計(jì)算出簽名哈希后，JWT頭，有效載荷和簽名哈希的三個(gè)部分組合成一個(gè)字符串，每個(gè)部分用"."分 隔，就構(gòu)成整個(gè)JWT對(duì)象
  

2.3 jwt核心

• 1）給用戶頒發(fā)的token值相當(dāng)于一把鎖，服務(wù)器端的秘鑰相當(dāng)于一把鑰匙

• 2）每次客戶端請(qǐng)求都會(huì)攜帶這把鎖，服務(wù)器端用秘鑰去開這把鎖，若果無法打開就證明是偽造的

2.4 jwt特點(diǎn)分析

• 1、JWT的最大缺點(diǎn)是服務(wù)器不保存會(huì)話狀態(tài)，所以在使用期間不可能取消令牌或更改令牌的權(quán)

  限，一旦JWT簽發(fā)，在有效期內(nèi)將會(huì)一直有效。

• 2、JWT本身包含認(rèn)證信息，因此一旦信息泄露，任何人都可以獲得令牌的所有權(quán)限。

• 3、為了減少盜用和竊取，JWT不建議使用HTTP協(xié)議來傳輸代碼，而是使用加密的HTTPS協(xié)議進(jìn)行

  傳輸。

間不可能取消令牌或更改令牌的權(quán)

限，一旦JWT簽發(fā)，在有效期內(nèi)將會(huì)一直有效。

• 2、JWT本身包含認(rèn)證信息，因此一旦信息泄露，任何人都可以獲得令牌的所有權(quán)限。

• 3、為了減少盜用和竊取，JWT不建議使用HTTP協(xié)議來傳輸代碼，而是使用加密的HTTPS協(xié)議進(jìn)行

  傳輸。

• 4、JWT不僅可用于認(rèn)證，還可用于信息交換，善用JWT有助于減少服務(wù)器請(qǐng)求數(shù)據(jù)庫的次數(shù)。