全棧項目|小書架|服務器開發-JWT 詳解

JWT

官方簡介：Introduction to JSON Web Tokens

文章基本是官網內容的翻譯，英文不錯的同窗可點擊上面的連接直接看英文文檔。

什麼是 JWT

JWT全稱是JSON Web Token（JWT）是一個開放標準（RFC 7519），它定義了一種緊湊且自包含的方式，用於在各方之間做爲JSON對象安全地傳輸信息。因爲此信息是通過數字簽名的，所以能夠被驗證和信任。

可使用密鑰（HMAC算法）或使用RSA或ECDSA的公用/專用密鑰對對JWT進行簽名。

何時使用 JWT 驗證

• 受權（Authorization）
  這是使用JWT的最多見狀況。一旦用戶登陸，每一個後續請求將包括JWT，從而容許用戶訪問該令牌容許的路由，服務和資源。單一登陸是當今普遍使用JWT的一項功能，由於它的開銷很小而且能夠在不一樣的域中輕鬆使用。
• 信息交換（Information Exchange）
JWT是在各方之間安全地傳輸信息的好方法。由於能夠對JWT進行簽名（例如，使用公鑰/私鑰對），因此您能夠確保發件人是他們所說的人。另外，因爲簽名是使用Header和payload計算的，所以您還能夠驗證內容是否未被篡改。

JWT 的結構格式

由三部分組成，這些部分由點.分隔，分別是：

• Header
• Payload
• Signature

所以，JWT一般以下所示。

xxxxx.yyyyy.zzzzz

Header

一般由兩部分組成：

• 令牌的類型（即JWT）
• 所使用的簽名算法，例如：HMAC SHA256或RSA。

例如：

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

而後，將此JSON經過Base64Url編碼以造成JWT的第一部分。

Payload

令牌的第二部分是有效負載，其中包含聲明。聲明是有關實體（一般是用戶）和其餘數據的聲明。共有三種類型的索賠： registered、public、private claims

• Registered claims
  這些是一組預約義的權利要求，不是強制性的，而是建議使用的，以提供一組有用的可互操做的權利要求。其中一些是：iss（發出者），exp（到期時間），sub（主題），aud（受衆） 等。
  Tip: 請注意，聲明名稱僅是三個字符，由於JWT是緊湊的。
• Public claims
  這些能夠由使用JWT的人員隨意定義。可是爲避免衝突，應在IANA JSON Web令牌註冊表中定義它們，或將其定義爲包含抗衝突名稱空間的URI。
• Private claims
  這些是自定義聲明，旨在在贊成使用它們的各方之間共享信息，既不是註冊聲明也不是公共聲明。

有效負載示例：

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

一樣須要Base64Url編碼，以造成JWT的第二部分。

Signature

簽名(Signature)用於驗證消息在整個過程當中沒有更改，而且對於使用私鑰進行簽名的令牌，它還能夠驗證JWT的發送者是它所說的真實身份。

例如，若是要使用HMAC SHA256算法，則將經過如下方式建立簽名：

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

將這三部分合並

輸出是三個由.分隔的Base64-URL字符串，能夠在HTML和HTTP環境中輕鬆傳遞這些字符串，與基於XML的標準（例如SAML）相比，它更緊湊。

下圖顯示了一個JWT，它已對先前的Header和Payload進行了編碼，並用一個Signature。

能夠在這個網頁 jwt.io Debugger 驗證和生成JWT

JWT 如何工做

在身份驗證中，當用戶使用其憑據成功登陸時，將返回令牌。因爲令牌是憑據，所以必須格外當心以防止安全問題。一般，令牌的有效時間不宜設置過長。

Tip: 因爲缺少安全性，您也不該該將敏感的會話數據存儲在瀏覽器存儲中。

每當用戶想要訪問受保護的路由或資源時，用戶代理一般應在Bearer模式中使用受權頭髮送JWT。Header的內容應以下所示：

Authorization: Bearer <token>

在某些狀況下，接口訪問並不須要身份受權。服務器的受保護路由將在Authorization Header中檢查JWT令牌是否有效，若是存在且有效，則將容許用戶訪問受保護的資源。

若是JWT包含必要的數據，則能夠減小查詢數據庫中某些操做的需求。

若是令牌是在Authorization Header中發送的，則跨域資源共享 （CORS） 不會成爲問題，由於它不使用cookie。

下圖顯示瞭如何獲取JWT並將其用於訪問API或資源：

1. 應用程序或客戶端向受權服務器請求受權。生產JWT令牌。
2. 授予受權後，受權服務器會將訪問令牌返回給應用程序。
3. 應用程序使用訪問令牌來訪問受保護的資源（例如API）。
4. 服務器檢查JWT令牌是否有效，返回對應結果給客戶端

下圖詳細的流程：

ps:請注意，使用簽名令牌，令牌或令牌中包含的全部信息都會暴露給用戶或其餘方，即便他們沒法更改它。這意味着您不該將機密信息放入令牌中。

爲何須要 JWT

對比 Simple Web Tokens (SWT) 和Security Assertion Markup Language Tokens (SAML)，看看使用JSON Web Tokens (JWT) 有什麼好處。

• 因爲JSON不如XML冗長，所以在編碼時JSON的大小也較小，從而使JWT比SAML更緊湊。這使得JWT是在HTML和HTTP環境中傳遞的不錯的選擇。
• 在安全方面，SWT只能使用HMAC算法進行對稱簽名。可是JWT和SAML令牌可使用X.509證書形式的公用/專用密鑰對進行簽名。與簽名JSON的簡單性相比，使用XML Digital Signature簽名XML而不引入模糊的安全漏洞是很是困難的。
• JSON解析器在大多數編程語言中都很常見，由於它們直接映射到對象。相反，XML沒有天然的文檔到對象映射。與SAML斷言相比，這使使用JWT更加容易。
• 關於用法，JWT是在Internet規模上使用的。這強調了在多個平臺（尤爲是移動平臺）上對JSON Web令牌進行客戶端處理的簡便性。

若是您想了解有關JSON Web令牌的更多信息，甚至開始使用它們在本身的應用程序中執行身份驗證，請瀏覽到 Auth0上的JSON Web令牌登陸 頁面。

---

諮詢請加微信：輕撩便可。