JWT 簡介

本文翻譯自JWT官方網站對JWT是什麼以及能作什麼的簡介。

JWT是一種用於雙方之間傳遞安全信息的簡潔的、URL安全的表述性聲明規範。JWT做爲一個開放的標準（RFC 7519），定義了一種簡潔的，自包含的方法用於通訊雙方之間以Json對象的形式安全的傳遞信息。由於數字簽名的存在，這些信息是可信的，JWT可使用HMAC算法或者是RSA的公私祕鑰對進行簽名。

• 簡潔(Compact): 能夠經過URL，POST參數或者在HTTP header發送，由於數據量小，傳輸速度也很快

• 自包含(Self-contained)：負載中包含了全部用戶所須要的信息，避免了屢次查詢數據庫

JWT的主要應用場景

• 身份認證
  在這種場景下，一旦用戶完成了登錄，在接下來的每一個請求中包含JWT，能夠用來驗證用戶身份以及對路由，服務和資源的訪問權限進行驗證。因爲它的開銷很是小，能夠輕鬆的在不一樣域名的系統中傳遞，全部目前在單點登陸（SSO）中比較普遍的使用了該技術。

• 信息交換
  在通訊的雙方之間使用JWT對數據進行編碼是一種很是安全的方式，因爲它的信息是通過簽名的，能夠確保發送者發送的信息是沒有通過僞造的。

JWT的結構

JWT包含了使用.分隔的三部分：

• Header 頭部

• Payload 負載

• Signature 簽名

其結構看起來是這樣的

xxxxx.yyyyy.zzzzz

Header

在header中一般包含了兩部分：token類型和採用的加密算法。

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

接下來對這部份內容使用 Base64Url 編碼組成了JWT結構的第一部分。

Payload

Token的第二部分是負載，它包含了claim， Claim是一些實體（一般指的用戶）的狀態和額外的元數據，有三種類型的claim： reserved, public 和 private.

• Reserved claims: 這些claim是JWT預先定義的，在JWT中並不會強制使用它們，而是推薦使用，經常使用的有 iss（簽發者）, exp（過時時間戳）, sub（面向的用戶）, aud（接收方）, iat（簽發時間）。

• Public claims：根據須要定義本身的字段，注意應該避免衝突

• Private claims：這些是自定義的字段，能夠用來在雙方之間交換信息

負載使用的例子：

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

上述的負載須要通過Base64Url編碼後做爲JWT結構的第二部分。

Signature

建立簽名須要使用編碼後的header和payload以及一個祕鑰，使用header中指定簽名算法進行簽名。例如若是但願使用HMAC SHA256算法，那麼簽名應該使用下列方式建立：

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

簽名用於驗證消息的發送者以及消息是沒有通過篡改的。

完整的JWT

JWT格式的輸出是以.分隔的三段Base64編碼，與SAML等基於XML的標準相比，JWT在HTTP和HTML環境中更容易傳遞。

下列的JWT展現了一個完整的JWT格式，它拼接了以前的Header， Payload以及祕鑰簽名：

如何使用JWT？

在身份鑑定的實現中，傳統方法是在服務端存儲一個session，給客戶端返回一個cookie，而使用JWT以後，當用戶使用它的認證信息登錄系統以後，會返回給用戶一個JWT，用戶只須要本地保存該token（一般使用local storage，也可使用cookie）便可。

當用戶但願訪問一個受保護的路由或者資源的時候，一般應該在Authorization頭部使用Bearer模式添加JWT，其內容看起來是下面這樣：

Authorization: Bearer <token>

由於用戶的狀態在服務端的內存中是不存儲的，因此這是一種無狀態的認證機制。服務端的保護路由將會檢查請求頭Authorization中的JWT信息，若是合法，則容許用戶的行爲。因爲JWT是自包含的，所以減小了須要查詢數據庫的須要。

JWT的這些特性使得咱們能夠徹底依賴其無狀態的特性提供數據API服務，甚至是建立一個下載流服務。由於JWT並不使用Cookie的，因此你可使用任何域名提供你的API服務而不須要擔憂跨域資源共享問題（CORS）。

下面的序列圖展現了該過程：

爲何要使用JWT？

相比XML格式，JSON更加簡潔，編碼以後更小，這使得JWT比SAML更加簡潔，更加適合在HTML和HTTP環境中傳遞。

在安全性方面，SWT只可以使用HMAC算法和共享的對稱祕鑰進行簽名，而JWT和SAML token則可使用X.509認證的公私祕鑰對進行簽名。與簡單的JSON相比，XML和XML數字簽名會引入複雜的安全漏洞。

由於JSON能夠直接映射爲對象，在大多數編程語言中都提供了JSON解析器，而XML則沒有這麼天然的文檔-對象映射關係，這就使得使用JWT比SAML更方便。

---

原文： Introduction to JSON Web Tokens