瞭解JSON Web令牌(JWT)

 JSON Web Token（JWT）是目前最流行的跨域身份驗證解決方案。

(一) 跨域身份驗證

Internet服務沒法與用戶身份驗證分開。

1. 用戶向服務器發送用戶名和密碼。
2. 驗證服務器後，相關數據（如用戶角色，登陸時間等）將保存在當前會話中。
3. 服務器向用戶返回session_id，session信息都會寫入到用戶的Cookie。
4. 用戶的每一個後續請求都將經過在Cookie中取出session_id傳給服務器。
5. 服務器收到session_id並對比以前保存的數據，確認用戶的身份。

缺點：

1.最大的問題是：沒有分佈式架構，沒法支持橫向擴展。若是使用一個服務器，該模式徹底沒有問題;

2.若是它是服務器羣集或面向服務的跨域體系結構的話，則須要一個統一的session數據庫庫來保存會話數據實現共享，這樣負載均衡下的每一個服務器才能夠正確的驗證用戶身份。

實例：

舉一個實際中常見的單點登錄的需求：站點A和站點B提供同一公司的相關服務。如今要求用戶只須要登陸其中一個網站，而後它就會自動登陸到另外一個網站。怎麼作？

解決方案一: 持久化session數據

      持久化session數據，寫入數據庫或文件持久層等。收到請求後，驗證服務從持久層請求數據。

該解決方案的優勢在於架構清晰，而缺點是架構修改比較費勁，整個服務的驗證邏輯層都須要重寫，工做量相對較大。

並且因爲依賴於持久層的數據庫或者問題系統，會有單點風險，若是持久層失敗，整個認證體系都會掛掉。

一種靈活的解決方案：

       經過客戶端保存數據，而服務器根本不保存會話數據，每一個請求都被髮送回服務器。 JWT是這種解決方案的表明。

 

JWT的原則：

JWT的原則是在服務器身份驗證以後，將生成一個JSON對象並將其發送回用戶，以下：

{
"UserName": "Chongchong",
"Role": "Admin",
"Expire": "2018-08-08 20:15:56"
}

當用戶與服務器通訊時，客戶在請求中發回JSON對象。服務器僅依賴於這個JSON對象來標識用戶。

服務器不保存任何會話數據，即服務器變爲無狀態，使其更容易擴展。

 

JWT的數據結構：

典型的，一個JWT看起來以下圖：

1. JWT的三個部分以下。JWT頭、有效載荷和簽名。
2. JWT對象爲一個很長的字符串，字符之間經過"."分隔符分爲三個子串。 
3. JWT對象爲一個長字串，各字串之間也沒有換行符。
4. 用不一樣顏色表示了，每個子串表示了一個功能塊。

 

1.1 JWT頭：

 JWT頭部分是一個描述JWT元數據的JSON對象，一般以下所示：

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

*alg屬性表示簽名使用的算法，默認爲HMAC SHA256（寫爲HS256）。

*typ屬性表示令牌的類型，JWT令牌統一寫爲JWT。

最後，使用Base64 URL算法將上述JSON對象轉換爲字符串保存。

 

1.2 有效載荷：

有效載荷部分，是JWT的主體內容部分，也是一個JSON對象，包含須要傳遞的數據。

JWT指定七個默認字段供選擇：

iss：發行人
exp：到期時間
sub：主題
aud：用戶
nbf：在此以前不可用
iat：發佈時間
jti：JWT ID用於標識該JWT

除以上默認字段外，咱們還能夠自定義私有字段，以下

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

默認狀況下JWT是未加密的，任何人均可以解讀其內容，所以不要構建隱私信息字段，存放保密信息，以防止信息泄露。

最後，使用Base64 URL算法將上述JSON對象轉換爲字符串保存。

 

1.3 簽名哈希:

簽名哈希部分是對上面兩部分數據簽名，經過指定的算法生成哈希，以確保數據不會被篡改。

首先，須要指定一個密碼（secret）。該密碼僅僅爲保存在服務器中，而且不能向用戶公開。

而後，使用標頭中指定的簽名算法（默認狀況下爲HMAC SHA256）根據如下公式生成簽名。

HMACSHA256(base64UrlEncode(header) + "."+base64UrlEncode(payload), secret)

構成整個JWT對象：在計算出簽名哈希後，JWT頭，有效載荷和簽名哈希的三個部分組合成一個字符串，每一個部分用"."分隔；

1.4 Base64URL算法:

 JWT頭和有效載荷序列化的算法都用到了Base64URL。該算法和常見Base64算法相似，稍有差異。

做爲令牌的JWT能夠放在URL中（例如api.example/?token=xxx）；

Base64中用的三個字符是"+"，"/"和"="，因爲在URL中有特殊含義，所以Base64URL中對他們作了替換："="去掉，"+"用"-"替換，"/"用"_"替換，這就是Base64URL算法。

 

1.5 JWT的用法

客戶端接收服務器返回的JWT，將其存儲在Cookie或localStorage中。

此後，客戶端將在與服務器交互中都會帶JWT。

若是將它存儲在Cookie中，就能夠自動發送，可是不會跨域。

所以通常是將它放入HTTP請求的Header Authorization字段中。

Authorization: Bearer

當跨域時，也能夠將JWT被放置於POST請求的數據主體中。

 

JWT問題和趨勢：

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

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

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

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

五、JWT自己包含認證信息，所以一旦信息泄露，任何人均可以得到令牌的全部權限。爲了減小盜用，JWT的有效期不宜設置太長。對於某些重要操做，用戶在使用時應該每次都進行進行身份驗證。

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