最新消息：免費取得JWT 手冊，深入了解 JWT！
JSON 網路代幣 (JWT) 是一種開放標準 (RFC 7519)，定義一種精簡且獨立的方式，可作為 JSON 物件在各方之間安全地傳輸資訊。此資訊可以驗證和信任，因為它是經過數位簽章的。JWT 可以使用密碼 (搭配HMAC 演算法) 或使用RSA 或ECDSA 的公開/私人金鑰對進行簽章。
儘管 JWT 可以加密以在各方之間提供機密性，但我們將專注於已簽章的代幣。已簽章的代幣可以驗證其中包含的宣告的完整性，而加密的代幣會隱藏這些宣告，以避免其他方看到。當使用公開/私人金鑰對簽章代幣時，簽章也會證明只有持有私人金鑰的一方才是簽章的一方。
以下是一些 JSON 網路代幣有用的場景
授權：這是使用 JWT 最常見的場景。一旦使用者登入，後續的每個要求都會包含 JWT，讓使用者可以存取該代幣允許的路由、服務和資源。單一登入是一種廣泛使用 JWT 的功能，因為它的負擔小，而且可以輕鬆地在不同網域中使用。
資訊交換：JSON 網路代幣是一種在各方之間安全傳輸資訊的好方法。由於 JWT 可以簽章（例如，使用公開/私人金鑰對），因此您可以確定寄件者就是他們自稱的寄件者。此外，由於簽章是使用標頭和有效負載計算出來的，因此您也可以驗證內容未被竄改。
在精簡形式中，JSON 網路代幣包含三個部分，以句點 (.) 分隔，分別是
因此，JWT 通常看起來像以下內容。
xxxxx.yyyyy.zzzzz
讓我們分解不同的部分。
標頭通常包含兩個部分：令牌類型（即 JWT）和使用的簽署演算法，例如 HMAC SHA256 或 RSA。
例如
{
"alg": "HS256",
"typ": "JWT"
}
然後，將此 JSON Base64Url 編碼以形成 JWT 的第一部分。
令牌的第二部分是載荷，其中包含宣告。宣告是關於實體（通常是使用者）和附加資料的陳述。宣告有三種類型：已註冊、公開和私人宣告。
已註冊宣告：這些是一組預定義的宣告，雖然不是強制性的，但建議使用，以提供一組有用的、可互操作的宣告。其中一些是：iss（發行者）、exp（到期時間）、sub（主旨）、aud（受眾）和其他。
請注意，宣告名稱只有三個字元長，因為 JWT 旨在精簡。
公開宣告：這些可以由使用 JWT 的人隨意定義。但為了避免衝突，它們應該在IANA JSON Web Token Registry中定義，或定義為包含防衝突命名空間的 URI。
私人宣告：這些是自訂宣告，用於在同意使用它們的各方之間共享資訊，既不是已註冊宣告也不是公開宣告。
範例載荷可以是
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然後將載荷Base64Url 編碼以形成 JSON Web Token 的第二部分。
請注意，對於已簽署的令牌，這些資訊雖然受到防篡改保護，但任何人都可以讀取。除非已加密，否則請勿將機密資訊放入 JWT 的載荷或標頭元素中。
若要建立簽章部分，您必須取得編碼標頭、編碼載荷、機密、標頭中指定的演算法，並對其進行簽署。
例如，如果您想使用 HMAC SHA256 演算法，則會以以下方式建立簽章
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
簽章用於驗證訊息在傳輸過程中未被變更，並且對於使用私鑰簽署的令牌，它還可以驗證 JWT 的發送者是否為自稱的發送者。
輸出是三個以點分隔的 Base64-URL 字串，可以在 HTML 和 HTTP 環境中輕鬆傳遞，同時比基於 XML 的標準（例如 SAML）更精簡。
以下顯示一個 JWT，其中編碼了先前的標頭和有效負載，並使用一個機密簽署。 
如果您想使用 JWT 並將這些概念付諸實踐，可以使用 jwt.io Debugger 來解碼、驗證和產生 JWT。
在驗證中，當使用者使用其憑證成功登入時，將會傳回一個 JSON Web Token。由於令牌是憑證，因此必須非常小心以防止安全問題。一般來說，您不應保留令牌超過所需時間。
您也不應 由於缺乏安全性而將敏感的會話資料儲存在瀏覽器儲存空間中。
每當使用者想要存取受保護的路由或資源時，使用者代理應傳送 JWT，通常在 Authorization 標頭中使用 Bearer 架構。標頭的內容應如下所示
Authorization: Bearer <token>
在某些情況下，這可能是一種無狀態授權機制。伺服器的受保護路由將檢查 Authorization 標頭中的有效 JWT，如果存在，則使用者將被允許存取受保護的資源。如果 JWT 包含必要的資料，則查詢資料庫以進行某些操作的需求可能會減少，儘管這並不總是如此。
請注意，如果您透過 HTTP 標頭傳送 JWT 令牌，您應嘗試防止它們變得太大。有些伺服器不接受標頭中超過 8 KB 的內容。如果您嘗試在 JWT 令牌中嵌入過多資訊，例如包含使用者的所有權限，您可能需要一個替代方案，例如 Auth0 細粒度授權。
如果令牌在 Authorization 標頭中傳送，跨來源資源共用 (CORS) 將不會是一個問題，因為它不使用 cookie。
下圖顯示如何取得 JWT 並用於存取 API 或資源
/oauth/authorize 端點。請注意，對於已簽署的權杖，權杖中包含的所有資訊都會公開給使用者或其他方，即使他們無法變更這些資訊。這表示您不應將機密資訊放入權杖中。
讓我們來談談 JSON 網路權杖 (JWT) 與簡單網路權杖 (SWT) 和安全斷言標記語言權杖 (SAML) 相較之下有哪些好處。
由於 JSON 比 XML 較不冗長，因此編碼後的大小也較小，使得 JWT 比 SAML 更為精簡。這使得 JWT 成為在 HTML 和 HTTP 環境中傳遞的絕佳選擇。
在安全性方面，SWT 只能使用 HMAC 演算法由共用機密對稱簽署。然而，JWT 和 SAML 權杖可以使用 X.509 憑證形式的公鑰/私鑰對進行簽署。與簽署 JSON 的簡便性相比，在不引入不明安全性漏洞的情況下使用 XML 數位簽章簽署 XML 非常困難。
JSON 解析器在多數程式語言中都很常見，因為它們會直接對應到物件。相反地，XML 沒有自然的文件對物件對應。這使得使用 JWT 比使用 SAML 斷言更容易。
關於使用，JWT 用於網際網路規模。這突顯了在多個平台（尤其是行動裝置）上進行 JSON 網路權杖的用戶端處理的容易性。
比較編碼 JWT 和編碼 SAML 的長度
如果您想進一步了解 JSON 網路權杖，甚至開始使用它們在自己的應用程式中執行驗證，請瀏覽 Okta 的 Auth0 上的JSON 網路權杖登陸頁面。
立即開始使用 JWT
開始使用工具