【Web加密系列:三】10分鐘瞭解JSON Web令牌(JWT)

 

 

JSON Web Token(JWT)是目前最流行的跨域身份驗證解決方案。蟲蟲今天給大家介紹JWT的原理和用法。

1.跨域身份驗證

Internet服務無法與用戶身份驗證分開。一般過程如下。

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

2.驗證服務器後,相關數據(如用戶角色,登錄時間等)將保存在當前會話中。

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

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

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

 

 

這種模式最大的問題是,沒有分佈式架構,無法支持橫向擴展。如果使用一個服務器,該模式完全沒有問題。但是,如果它是服務器羣集或面向服務的跨域體系結構的話,則需要一個統一的session數據庫庫來保存會話數據實現共享,這樣負載均衡下的每個服務器纔可以正確的驗證用戶身份。

例如蟲蟲舉一個實際中常見的單點登陸的需求:站點A和站點B提供同一公司的相關服務。現在要求用戶只需要登錄其中一個網站,然後它就會自動登錄到另一個網站。怎麼做?

一種解決方案是聽過持久化session數據,寫入數據庫或文件持久層等。收到請求後,驗證服務從持久層請求數據。該解決方案的優點在於架構清晰,而缺點是架構修改比較費勁,整個服務的驗證邏輯層都需要重寫,工作量相對較大。而且由於依賴於持久層的數據庫或者問題系統,會有單點風險,如果持久層失敗,整個認證體系都會掛掉。

 

 

本文蟲蟲給大家介紹另外一種靈活的解決方案,通過客戶端保存數據,而服務器根本不保存會話數據,每個請求都被髮送回服務器。 JWT是這種解決方案的代表。

 

 

2. JWT的原則

JWT的原則是在服務器身份驗證之後,將生成一個JSON對象並將其發送回用戶,如下所示。

{

"UserName": "Chongchong",

"Role": "Admin",

"Expire": "2018-08-08 20:15:56"

}

之後,當用戶與服務器通信時,客戶在請求中發回JSON對象。服務器僅依賴於這個JSON對象來標識用戶。爲了防止用戶篡改數據,服務器將在生成對象時添加簽名(有關詳細信息,請參閱下文)。

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

3. JWT的數據結構

典型的,一個JWT看起來如下圖。

 

 

改對象爲一個很長的字符串,字符之間通過"."分隔符分爲三個子串。注意JWT對象爲一個長字串,各字串之間也沒有換行符,此處爲了演示需要,我們特意分行並用不同顏色表示了。每一個子串表示了一個功能塊,總共有以下三個部分:

JWT的三個部分如下。JWT頭、有效載荷和簽名,將它們寫成一行如下。

 

 

我們將在下面介紹這三個部分。

3.1 JWT頭

JWT頭部分是一個描述JWT元數據的JSON對象,通常如下所示。

{

"alg": "HS256",

"typ": "JWT"

}

在上面的代碼中,alg屬性表示簽名使用的算法,默認爲HMAC SHA256(寫爲HS256);typ屬性表示令牌的類型,JWT令牌統一寫爲JWT。

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

3.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.3簽名哈希

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

首先,需要指定一個密碼(secret)。該密碼僅僅爲保存在服務器中,並且不能向用戶公開。然後,使用標頭中指定的簽名算法(默認情況下爲HMAC SHA256)根據以下公式生成簽名。

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

secret)

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

3.4 Base64URL算法

如前所述,JWT頭和有效載荷序列化的算法都用到了Base64URL。該算法和常見Base64算法類似,稍有差別。

作爲令牌的JWT可以放在URL中(例如api.example/?token=xxx)。 Base64中用的三個字符是"+","/"和"=",由於在URL中有特殊含義,因此Base64URL中對他們做了替換:"="去掉,"+"用"-"替換,"/"用"_"替換,這就是Base64URL算法,很簡單把。

4. JWT的用法

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

此後,客戶端將在與服務器交互中都會帶JWT。如果將它存儲在Cookie中,就可以自動發送,但是不會跨域,因此一般是將它放入HTTP請求的Header Authorization字段中。

Authorization: Bearer

當跨域時,也可以將JWT被放置於POST請求的數據主體中。

5. JWT問題和趨勢

1、JWT默認不加密,但可以加密。生成原始令牌後,可以使用改令牌再次對其進行加密。

2、當JWT未加密方法是,一些私密數據無法通過JWT傳輸。

3、JWT不僅可用於認證,還可用於信息交換。善用JWT有助於減少服務器請求數據庫的次數。

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

5、JWT本身包含認證信息,因此一旦信息泄露,任何人都可以獲得令牌的所有權限。爲了減少盜用,JWT的有效期不宜設置太長。對於某些重要操作,用戶在使用時應該每次都進行進行身份驗證。

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章