1.COOKIE使用和優缺點

1.1 cookie原理： 使用者名稱+密碼

　　cookie是儲存在使用者瀏覽器端，使用者名稱和密碼等明文資訊

1.2 session使用原理

　　session是儲存在伺服器端的一段字串,相當於字典的key

1.使用者向伺服器傳送使用者名稱和密碼。

2.驗證伺服器後，相關資料（如使用者角色，登入時間等）將儲存在當前會話中。

3.伺服器向用戶返回session_id，session資訊都會寫入到使用者的Cookie。

4.使用者的每個後續請求都將通過在Cookie中取出session_id傳給伺服器。

5.伺服器收到session_id並對比之前儲存的資料，確認使用者的身份。

1.3 session使用缺點

　　1.這種模式最大的問題是，沒有分散式架構，無法支援橫向擴充套件。

　　2.如果使用一個伺服器，該模式完全沒有問題。

　　3.但是，如果它是伺服器群集或面向服務的跨域體系結構的話，則需要一個統一的session資料庫庫來儲存會話資料實現共享，

　　4.這樣負載均衡下的每個伺服器才可以正確的驗證使用者身份。

1.4 常用解決session方法

　　1.一種解決方案是通過持久化session資料，寫入資料庫或檔案持久層等。

　　2.收到請求後，驗證服務從持久層請求資料。

　　3.依賴於持久層的資料庫或者問題系統，會有單點風險，如果持久層失敗，整個認證體系都會掛掉。

第一種：沒有session持久化

　　　　沒有分散式架構，無法支援橫向擴充套件

　　　　session預設儲存在記憶體中，如果把程式碼部署在多臺機器上，session儲存到了其中某一臺機器的記憶體中

　　　　使用者如果在A機器上登入，只有A機器的記憶體中存了這個session的key，如果請求nginx路由到B機器，B機器記憶體中沒有這個session資料，就需要從新登入

第二種：寫入資料庫或檔案持久層

　　　　解決了橫向擴充套件問題

　　　　資料庫持久層出現問題，所有叢集都沒辦法登入， 單點故障

　　　　如果資料放到mysql中，使用者量過大，查詢很慢，效率很低

2.JWT介紹

2.1 JWT原則

　　　　最簡單理解：jwt本質就是， 把使用者資訊通過加密後生成的一個字串

JWT的原則是在伺服器身份驗證之後，將生成一個JSON物件並將其傳送回用戶 
{
    "UserName": "Chongchong",
    "Role": "Admin", "Expire":
    "2018-08-08 20:15:56" 
}
之後，當用戶與伺服器通訊時，客戶在請求中發回JSON物件，伺服器僅依賴於這個JSON物件來標識使用者。 為了防止使用者篡改資料，伺服器將在生成物件時添加簽名（有關詳細資訊，請參閱下文）。
伺服器不儲存任何會話資料，即伺服器變為無狀態，使其更容易擴充套件

2.2 JWT的資料結構

　　1）jwt頭：JWT頭部分是一個描述JWT元資料的JSON物件

　　2）有效載荷：七個預設欄位+自定義私有欄位

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

部分： JWT頭

base64UrlEncode(header) --->字串

# JWT頭部分是一個描述JWT元資料的JSON物件，通常如下所示。 
{
    "alg": "HS256", 
    "typ": "JWT" 
}
# 1）alg屬性表示簽名使用的演算法，預設為HMAC SHA256（寫為HS256）；
# 2）typ屬性表示令牌的型別，JWT令牌統一寫為JWT。
# 3）最後，使用Base64 URL演算法將上述JSON物件轉換為字串儲存。

第二部分： 有效載荷 沒有敏感資料的使用者資訊

base64UrlEncode(payload) --->字串

#1、有效載荷部分，是JWT的主體內容部分，也是一個JSON物件，包含需要傳遞的資料。 JWT指定七個預設 欄位供選擇欄位供選擇。 
''' 
iss：發行人 
exp：到期時間 
sub：主題 
aud：使用者 
nbf：在此之前不可用 
iat：釋出時間 
jti：JWT ID用於標識該JWT 
''' 

#2、除以上預設欄位外，我們還可以自定義私有欄位，如下例：
{
    "sub": "1234567890", 
    "name": "chongchong", 
    "admin": true 
}

#3、注意 預設情況下JWT是未加密的，任何人都可以解讀其內容，因此不要構建隱私資訊欄位，存放保密資訊，以防 止資訊洩露。 JSON物件也使用Base64 URL演算法轉換為字串儲存。

第三部分： 簽名雜湊

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

# 1.簽名雜湊部分是對上面兩部分資料簽名，通過指定的演算法生成雜湊，以確保資料不會被篡改。 
# 2.首先，需要指定一個密碼（secret），該密碼僅僅為儲存在伺服器中，並且不能向用戶公開。
# 3.然後，使用標頭中指定的簽名演算法（預設情況下為HMAC SHA256）根據以下公式生成簽名。 
# 4.HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret) 
# 5.在計算出簽名雜湊後，JWT頭，有效載荷和簽名雜湊的三個部分組合成一個字串，每個部分用"."分 隔，就構成整個JWT物件。

2.3 jwt核心

　　1）給使用者頒發的token值相當於一把鎖，伺服器端的祕鑰相當於一把鑰匙

　　2）每次客戶端請求都會攜帶這把鎖，伺服器端用祕鑰去開這把鎖，若果無法開啟就證明是偽造的

2.4 jwt特點分析

　　1、JWT的最大缺點是伺服器不儲存會話狀態，所以在使用期間不可能取消令牌或更改令牌的許可權，一旦JWT簽發，在有效期內將會一直有效。

　　2、JWT本身包含認證資訊，因此一旦資訊洩露，任何人都可以獲得令牌的所有許可權。

　　3、為了減少盜用和竊取，JWT不建議使用HTTP協議來傳輸程式碼，而是使用加密的HTTPS協議進行傳輸。

　　4、JWT不僅可用於認證，還可用於資訊交換，善用JWT有助於減少伺服器請求資料庫的次數。