本篇文章給大家?guī)砹岁P(guān)于JWT的相關(guān)知識，其中主要介紹了什么是JWT？JWT的原理以及用法是什么？感興趣的朋友，下面一起來看一下吧，希望對大家有幫助。

JSON Web Token（縮寫 JWT）是目前最流行的跨域認證解決方案，本文介紹它的原理和用法。

一、跨域認證的問題

互聯(lián)網(wǎng)服務(wù)離不開用戶認證。一般流程是下面這樣。

1、用戶向服務(wù)器發(fā)送用戶名和密碼。

2、服務(wù)器驗證通過后，在當前對話（session）里面保存相關(guān)數(shù)據(jù)，比如用戶角色、登錄時間等等。

3、服務(wù)器向用戶返回一個 session_id，寫入用戶的 Cookie。

4、用戶隨后的每一次請求，都會通過 Cookie，將 session_id 傳回服務(wù)器。

5、服務(wù)器收到 session_id，找到前期保存的數(shù)據(jù)，由此得知用戶的身份。

這種模式的問題在于，擴展性（scaling）不好。單機當然沒有問題，如果是服務(wù)器集群，或者是跨域的服務(wù)導向架構(gòu)，就要求 session 數(shù)據(jù)共享，每臺服務(wù)器都能夠讀取 session。

舉例來說，A 網(wǎng)站和 B 網(wǎng)站是同一家公司的關(guān)聯(lián)服務(wù)。現(xiàn)在要求，用戶只要在其中一個網(wǎng)站登錄，再訪問另一個網(wǎng)站就會自動登錄，請問怎么實現(xiàn)？

一種解決方案是 session 數(shù)據(jù)持久化，寫入數(shù)據(jù)庫或別的持久層。各種服務(wù)收到請求后，都向持久層請求數(shù)據(jù)。這種方案的優(yōu)點是架構(gòu)清晰，缺點是工程量比較大。另外，持久層萬一掛了，就會單點失敗。

另一種方案是服務(wù)器索性不保存 session 數(shù)據(jù)了，所有數(shù)據(jù)都保存在客戶端，每次請求都發(fā)回服務(wù)器。JWT 就是這種方案的一個代表。

二、JWT 的原理

JWT 的原理是，服務(wù)器認證以后，生成一個 JSON 對象，發(fā)回給用戶，就像下面這樣。

{   "姓名": "張三",   "角色": "管理員",   "到期時間": "2018年7月1日0點0分" }

以后，用戶與服務(wù)端通信的時候，都要發(fā)回這個 JSON 對象。服務(wù)器完全只靠這個對象認定用戶身份。為了防止用戶篡改數(shù)據(jù)，服務(wù)器在生成這個對象的時候，會加上簽名（詳見后文）。

服務(wù)器就不保存任何 session 數(shù)據(jù)了，也就是說，服務(wù)器變成無狀態(tài)了，從而比較容易實現(xiàn)擴展。

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

實際的 JWT 大概就像下面這樣。

它是一個很長的字符串，中間用點（.）分隔成三個部分。注意，JWT 內(nèi)部是沒有換行的，這里只是為了便于展示，將它寫成了幾行。

JWT 的三個部分依次如下。

• Header（頭部）

• Payload（負載）

• Signature（簽名）

寫成一行，就是下面的樣子。

Header.Payload.Signature

下面依次介紹這三個部分。

3.1 Header

Header 部分是一個 JSON 對象，描述 JWT 的元數(shù)據(jù)，通常是下面的樣子。

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

上面代碼中，alg屬性表示簽名的算法（algorithm），默認是 HMAC SHA256（寫成 HS256）；typ屬性表示這個令牌（token）的類型（type），JWT 令牌統(tǒng)一寫為JWT。

最后，將上面的 JSON 對象使用 Base64URL 算法（詳見后文）轉(zhuǎn)成字符串。

3.2 Payload

Payload 部分也是一個 JSON 對象，用來存放實際需要傳遞的數(shù)據(jù)。JWT 規(guī)定了7個官方字段，供選用。

• iss (issuer)：簽發(fā)人

• exp (expiration time)：過期時間

• sub (subject)：主題

• aud (audience)：受眾

• nbf (Not Before)：生效時間

• iat (Issued At)：簽發(fā)時間

• jti (JWT ID)：編號

除了官方字段，你還可以在這個部分定義私有字段，下面就是一個例子。

{   "sub": "1234567890",   "name": "John Doe",   "admin": true }

注意，JWT 默認是不加密的，任何人都可以讀到，所以不要把秘密信息放在這個部分。

這個 JSON 對象也要使用 Base64URL 算法轉(zhuǎn)成字符串。

3.3 Signature

Signature 部分是對前兩部分的簽名，防止數(shù)據(jù)篡改。

首先，需要指定一個密鑰（secret）。這個密鑰只有服務(wù)器才知道，不能泄露給用戶。然后，使用 Header 里面指定的簽名算法（默認是 HMAC SHA256），按照下面的公式產(chǎn)生簽名。

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

算出簽名以后，把 Header、Payload、Signature 三個部分拼成一個字符串，每個部分之間用"點"（.）分隔，就可以返回給用戶。

3.4 Base64URL

前面提到，Header 和 Payload 串型化的算法是 Base64URL。這個算法跟 Base64 算法基本類似，但有一些小的不同。

JWT 作為一個令牌（token），有些場合可能會放到 URL（比如 api.example.com/?token=xxx）。Base64 有三個字符+、/和=，在 URL 里面有特殊含義，所以要被替換掉：=被省略、+替換成-，/替換成_ 。這就是 Base64URL 算法。

四、JWT 的使用方式

客戶端收到服務(wù)器返回的 JWT，可以儲存在 Cookie 里面，也可以儲存在 localStorage。

此后，客戶端每次與服務(wù)器通信，都要帶上這個 JWT。你可以把它放在 Cookie 里面自動發(fā)送，但是這樣不能跨域，所以更好的做法是放在 HTTP 請求的頭信息Authorization字段里面。

Authorization: Bearer <token>

另一種做法是，跨域的時候，JWT 就放在 POST 請求的數(shù)據(jù)體里面。

五、JWT 的幾個特點

（1）JWT 默認是不加密，但也是可以加密的。生成原始 Token 以后，可以用密鑰再加密一次。

（2）JWT 不加密的情況下，不能將秘密數(shù)據(jù)寫入 JWT。

（3）JWT 不僅可以用于認證，也可以用于交換信息。有效使用 JWT，可以降低服務(wù)器查詢數(shù)據(jù)庫的次數(shù)。

（4）JWT 的最大缺點是，由于服務(wù)器不保存 session 狀態(tài)，因此無法在使用過程中廢止某個 token，或者更改 token 的權(quán)限。也就是說，一旦 JWT 簽發(fā)了，在到期之前就會始終有效，除非服務(wù)器部署額外的邏輯。

（5）JWT 本身包含了認證信息，一旦泄露，任何人都可以獲得該令牌的所有權(quán)限。為了減少盜用，JWT 的有效期應(yīng)該設(shè)置得比較短。對于一些比較重要的權(quán)限，使用時應(yīng)該再次對用戶進行認證。

（6）為了減少盜用，JWT 不應(yīng)該使用 HTTP 協(xié)議明碼傳輸，要使用 HTTPS 協(xié)議傳輸。

推薦學習：《JavaScript視頻教程》