1. 程式人生 > >全棧專案|小書架|伺服器開發-JWT 詳解

全棧專案|小書架|伺服器開發-JWT 詳解

JWT

官方簡介:Introduction to JSON Web Tokens

文章基本是官網內容的翻譯,英文不錯的同學可點選上面的連結直接看英文文件。

什麼是 JWT

JWT全稱是JSON Web Token(JWT)是一個開放標準(RFC 7519),它定義了一種緊湊且自包含的方式,用於在各方之間作為JSON物件安全地傳輸資訊。由於此資訊是經過數字簽名的,因此可以被驗證和信任。

可以使用金鑰(HMAC演算法)或使用RSAECDSA的公用/專用金鑰對對JWT進行簽名。

什麼時候使用 JWT 驗證

  • 授權(Authorization)
    這是使用JWT的最常見情況。一旦使用者登入,每個後續請求將包括JWT
    ,從而允許使用者訪問該令牌允許的路由,服務和資源。單一登入是當今廣泛使用JWT的一項功能,因為它的開銷很小並且可以在不同的域中輕鬆使用。
  • 資訊交換(Information Exchange)
    JWT是在各方之間安全地傳輸資訊的好方法。因為可以對JWT進行簽名(例如,使用公鑰/私鑰對),所以您可以確保發件人是他們所說的人。另外,由於簽名是使用Headerpayload計算的,因此您還可以驗證內容是否未被篡改。

JWT 的結構格式

由三部分組成,這些部分由點.分隔,分別是:

  • Header
  • Payload
  • Signature

因此,JWT通常如下所示。

xxxxx.yyyyy.zzzzz

通常由兩部分組成:

  • 令牌的型別(即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字串,可以在HTMLHTTP環境中輕鬆傳遞這些字串,與基於XML的標準(例如SAML)相比,它更緊湊。

下圖顯示了一個JWT,它已對先前的HeaderPayload進行了編碼,並用一個Signature

可以在這個網頁 jwt.io Debugger 驗證和生成JWT

JWT 如何工作

在身份驗證中,當用戶使用其憑據成功登入時,將返回令牌。由於令牌是憑據,因此必須格外小心以防止安全問題。通常,令牌的有效時間不宜設定過長。

Tip: 由於缺乏安全性,您也不應該將敏感的會話資料儲存在瀏覽器儲存中。

每當使用者想要訪問受保護的路由或資源時,使用者代理通常應在Bearer模式中使用授權頭髮送JWTHeader的內容應如下所示:

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的大小也較小,從而使JWTSAML更緊湊。這使得JWT是在HTMLHTTP環境中傳遞的不錯的選擇。
  • 在安全方面,SWT只能使用HMAC演算法進行對稱簽名。但是JWTSAML令牌可以使用X.509證書形式的公用/專用金鑰對進行簽名。與簽名JSON的簡單性相比,使用XML Digital Signature簽名XML而不引入模糊的安全漏洞是非常困難的。
  • JSON解析器在大多數程式語言中都很常見,因為它們直接對映到物件。相反,XML沒有自然的文件到物件對映。與SAML斷言相比,這使使用JWT更加容易。
  • 關於用法,JWT是在Internet規模上使用的。這強調了在多個平臺(尤其是移動平臺)上對JSON Web令牌進行客戶端處理的簡便性。

如果您想了解有關JSON Web令牌的更多資訊,甚至開始使用它們在自己的應用程式中執行身份驗證,請瀏覽到 Auth0上的JSON Web令牌登入 頁面。


諮詢請加微信:輕撩即可。