05: jwt原理&使用

1.1 COOKIE使用和優缺點

　　  參考博客：https://baijiahao.baidu.com/s?id=1608021814182894637&wfr=spider&for=pc

　　一、cookie使用原理

　　　　　　1.用戶向服務器發送用戶名和密碼。

　　　　　　2.驗證服務器後，相關數據（如用戶角色，登陸時間等）將保存在當前會話中。

　　　　　　3.服務器向用戶返回session_id，session信息都會寫入到用戶的Cookie。

　　　　　　4.用戶的每一個後續請求都將經過在Cookie中取出session_id傳給服務器。

　　　　　　5.服務器收到session_id並對比以前保存的數據，確認用戶的身份。

　　　　　　

　　二、session使用缺點

　　　　　　1. 這種模式最大的問題是，沒有分佈式架構，沒法支持橫向擴展。
　　　　　　2. 若是使用一個服務器，該模式徹底沒有問題。
　　　　　　3. 可是，若是它是服務器羣集或面向服務的跨域體系結構的話，則須要一個統一的session數據庫庫來保存會話數據實現共享，
　　　　　　4. 這樣負載均衡下的每一個服務器才能夠正確的驗證用戶身份。

　　三、經常使用解決session方法

　　　　　　1. 一種解決方案是經過持久化session數據，寫入數據庫或文件持久層等。
　　　　　　2. 收到請求後，驗證服務從持久層請求數據。
　　　　　　3. 依賴於持久層的數據庫或者問題系統，會有單點風險，若是持久層失敗，整個認證體系都會掛掉。

 　　　　　　

1.2 JWT介紹

　　一、jwt原則

JWT的原則是在服務器身份驗證以後，將生成一個JSON對象並將其發送回用戶
{
"UserName": "Chongchong",
"Role": "Admin",
"Expire": "2018-08-08 20:15:56"
}

以後，當用戶與服務器通訊時，客戶在請求中發回JSON對象，服務器僅依賴於這個JSON對象來標識用戶。
爲了防止用戶篡改數據，服務器將在生成對象時添加簽名（有關詳細信息，請參閱下文）。
服務器不保存任何會話數據，即服務器變爲無狀態，使其更容易擴展

　　二、JWT的數據結構

　　　　　　1）jwt頭：JWT頭部分是一個描述JWT元數據的JSON對象

　　　　　　2）有效載荷：七個默認字段+自定義私有字段

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

　　　　　　

　　　　1）JWT頭

# JWT頭部分是一個描述JWT元數據的JSON對象，一般以下所示。
{
"alg": "HS256",
"typ": "JWT"
}
# 1）alg屬性表示簽名使用的算法，默認爲HMAC SHA256（寫爲HS256）；
# 2）typ屬性表示令牌的類型，JWT令牌統一寫爲JWT。
# 3）最後，使用Base64 URL算法將上述JSON對象轉換爲字符串保存。

　　　　2）有效載荷

#一、有效載荷部分，是JWT的主體內容部分，也是一個JSON對象，包含須要傳遞的數據。 JWT指定七個默認字段供選擇。
'''
iss：發行人
exp：到期時間
sub：主題
aud：用戶
nbf：在此以前不可用
iat：發佈時間
jti：JWT ID用於標識該JWT
'''

#二、除以上默認字段外，咱們還能夠自定義私有字段，以下例：
{
"sub": "1234567890",
"name": "chongchong",
"admin": true
}

#三、注意
默認狀況下JWT是未加密的，任何人均可以解讀其內容，所以不要構建隱私信息字段，存放保密信息，以防止信息泄露。
JSON對象也使用Base64 URL算法轉換爲字符串保存。

有效載荷

　　　　3）簽名哈希

# 1.簽名哈希部分是對上面兩部分數據簽名，經過指定的算法生成哈希，以確保數據不會被篡改。 # 2.首先，須要指定一個密碼（secret），該密碼僅僅爲保存在服務器中，而且不能向用戶公開。 # 3.而後，使用標頭中指定的簽名算法（默認狀況下爲HMAC SHA256）根據如下公式生成簽名。 # 4.HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret) # 5.在計算出簽名哈希後，JWT頭，有效載荷和簽名哈希的三個部分組合成一個字符串，每一個部分用"."分隔，就構成整個JWT對象。

　　三、jwt核心

　　　　　　1）給用戶頒發的token值至關於一把鎖，服務器端的祕鑰至關於一把鑰匙

　　　　　　2）每次客戶端請求都會攜帶這把鎖，服務器端用祕鑰去開這把鎖，若果沒法打開就證實是僞造的

　　四、jwt特色分析

　　　　　　一、JWT默認不加密，但能夠加密，生成原始令牌後，可使用改令牌再次對其進行加密。

　　　　　　二、當JWT未加密方法是，一些私密數據沒法經過JWT傳輸。

　　　　　　三、JWT不只可用於認證，還可用於信息交換，善用JWT有助於減小服務器請求數據庫的次數。

　　　　　　四、JWT的最大缺點是服務器不保存會話狀態，因此在使用期間不可能取消令牌或更改令牌的權限，一旦JWT簽發，在有效期內將會一直有效。

　　　　　　五、JWT自己包含認證信息，所以一旦信息泄露，任何人均可以得到令牌的全部權限。

　　　　　　六、爲了減小盜用和竊取，JWT不建議使用HTTP協議來傳輸代碼，而是使用加密的HTTPS協議進行傳輸。

 

 

 

 

 

 

111111111111111111111