JSON Web Tokens 简要介绍

• 什么是 JSON Web Tokens?
• 何时应该使用 JSON Web Tokens？
• JSON Web Tokens 数据结构是什么形式？
• JSON Web Tokens 是如何工作的？
• 我们为什么要使用 JSON Web Tokens？
• JWT解码和编码的区别

什么是 JSON Web Tokens?

JSON Web Tokens（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑（Compact）且自包含（Self-contained）的方式，用于在各方之间以 JSON 对象的形式安全地、高效地传输信息。JWT 可以使用密钥（使用HMAC算法）或使用 RSA 或 ECDSA 的公钥/私钥对进行签名，通过签名机制保障数据的完整性和真实性，防止 JWT 在传输过程中被篡改。

虽然 JWT 可以被加密，在各方之间传递，提升保密性，但是 JWT 默认情况下并不加密，其核心设计侧重于数字签名和验证机制，而非加密保护。因此，在这篇文章里，我们将重点关注签名令牌（signed token）。签名令牌可以验证其中包含的声明的完整性，而加密令牌则隐藏这些声明，使其无法被其他方访问。当令牌使用私钥（Private Key）签名时，必须使用成对的公钥（Public Key）验证令牌的签名，确保数据的完整性和安全性。

何时应该使用 JSON Web Tokens？

以下是 JSON Web Tokens 有用的一些场景：

• 身份验证和授权：这是使用 JWT 最常见的场景。用户登录后，每个后续请求都将包含 JWT，允许用户访问该令牌允许的路由、服务和资源。
• 单点登录：单点登录是当今广泛使用 JWT 的一项功能，因为它的开销很小，并且能够在不同的域中轻松使用。
• 信息交换：JWT 是在各方之间安全传输信息的良好方法。因为 JWT 有签名机制（例如：使用公钥/私钥对），因此你可以确定发送方就是他们所说的那个人。此外，由于签名是使用标头和有效载荷计算的，您还可以验证内容是否未被篡改。
• 前后端分离：JWT 也适合前后端分离的架构模式。在这种模式下，前端和后端通过 HTTP 请求进行通信，而没有直接的服务器端渲染（如传统的服务器端页面生成）。前端可以在随后的请求中自动携带这个令牌，而不需要每次都重新进行身份验证。

JSON Web Tokens 数据结构是什么形式？

在其紧凑的形式中，JSON Web Tokens 由三部分通过点号（.）连接组成，它们分别是：

1. Header
2. Payload
3. Signature

普遍情况下，JWT 数据格式如下所示：

xxxxx.yyyyy.zzzzz

接下来，我们继续对这三部分进一步讲解。

Header（标头）

标头通常由两部分组成：令牌的类型，即 JWT。以及使用的签名算法，如 HMAC 或 SHA256 或 RSA 等。

例如：

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

然后，这个 JSON 内容被 Base64URL 编码，形成 JWT 的第一部分数据。

Payload（有效载荷）

令牌的第二部分是有效载荷，也是令牌的主体部分，用于存储声明（claims）。这些声明是关于实体（通常是用户）和其他数据的声明。Payload 的结构有三种类型：注册声明、公共声明和私有声明。

• 注册声明：这些是 JWT 预定义的声明，它们不是强制性的，但推荐使用，以提供一组有用的、可互操作的声明。例如：iss（发行者）、exp（到期时间）、sub（主题）、aud（受众）、nbf（生效时间）、iat（签发时间）、jti（唯一标识）等。
请注意，声明名称只有三个字符长，因为 JWT 旨在保持紧凑。
• 公开声明：这些声明可以由使用 JWT 的人随意定义。但为了避免冲突，它们应该在 IANA JSON Web Tokens 注册表中定义，或者定义为包含防冲突命名空间的URI。
• 私人声明：这些是为在同意使用它们的各方之间共享信息而创建的自定义声明，既不是注册声明，也不是公开声明。

有效载荷（Payload）示例如下所示：

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

然后对有效载荷进行 Base64URL 编码，形成 JWT 的第二部分数据。

Signature（签名）

要创建签名部分，它必须获取编码的标头、编码的有效载荷、秘密、标头中指定的算法，并对其进行签名。

例如，如果你想使用 HMAC-SHA256 算法，则签名将按以下方式创建：

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

签名用于验证消息在传输过程中没有被篡改。并且，对使用私钥签名的令牌，它还可以验证 JWT 的发送者就是它许可的人。

将所有内容组合一起

如下数据，是由三个点分隔的 Base64URL 字符串，可以在 HTML 和 HTTP 环境中轻松传递，同时与基于 XML 的标准（如SAML）相比更紧凑。

下面展示了一个 JWT，它把标头和有效载荷 Base64URL 编码，并使用秘钥进行了签名。

如果你想使用 JWT 并将这些概念付诸实践，你可以使用 jwt.box3.cn 来解码、验证和生成 JWT。

JSON Web Tokens 是如何工作的？

在身份验证中，当用户使用其凭据成功登录时，将返回一个 JSON Web Tokens。由于令牌是凭证，因此必须非常小心地防止安全问题。一般来说，您不应该保留令牌超过所需的时间。

You also 不应该将敏感的会话数据存储在浏览器存储中，因为缺乏安全性。

每当用户想要访问受保护的路由或资源时，用户代理都应该使用 Bearer 模式在 Authorization 标头中发送 JWT。标头的内容应如下所示：

Authorization: Bearer <token>

在某些情况下，这可能是一种无状态授权机制。服务器的受保护路由将检查 Authorization 标头中的有效 JWT，如果存在，则允许用户访问受保护的资源。如果 JWT 包含必要的数据，则可以减少查询数据库进行某些操作的需要，尽管情况可能并非总是如此。

请注意，如果您通过 HTTP 标头发送 JWT 令牌，则应该注意内容体量。有一些服务器不接受标头中超过 8 KB 的数据。如果 JWT 需要包含更多的数据，可能是为了减少了数据库查询次数，但避免放入隐私数据。如果您尝试在 JWT 令牌中嵌入更多信息，例如通过包含所有用户的权限，您可能需要其他解决方案，例如 Auth0 细粒度授权。

如果令牌在 Authorization 标头中发送，则跨源资源共享（CORS）不会成为问题，因为它不使用 Cookie。

下图显示了如何获取 JWT 并使用它来访问 API 或资源：

请注意，对于签名令牌，令牌中包含的所有信息都暴露给用户或其他方，虽然他们无法更改内容。但是我们不应该在令牌中放置机密信息。

我们为什么要使用 JSON Web Tokens？

让我们讨论一下与简单 Web 令牌 (SWT) 和安全断言标记语言令牌 (SAML) 相比，JSON Web 令牌 (JWT) 的优势。

由于 JSON 比 XML 冗长，因此在编码时，它的尺寸也更小，使 JWT 比 SAML 更紧凑。这使得 JWT 成为在 HTML 和 HTTP 环境中传递的良好选择。

在安全性方面，SWT 只能使用 HMAC 算法通过共享密钥进行对称签名。但是，JWT 和 SAML 令牌可以使用 X.509 证书形式的公钥/私钥对进行签名。与 JSON 签名的简单性相比，在不引入模糊的安全漏洞的情况下对 XML 使用 XML 数字签名非常困难。

大多数编程语言中都普遍存在 JSON 解析器，因为它们直接映射到对象。相反，XML 没有自然的文档到对象的映射。这使得使用 JWT 比使用 SAML 断言更容易。

在使用方面，JWT 在互联网范围内使用。这突出了在多个平台上，尤其是移动平台上，客户端对 JSON Web 令牌的易于处理性。

JWT解码和编码的区别

对 JWT 编码涉及将标头和有效载荷转换为紧凑的 URL 安全格式。声明签名算法和令牌类型的标头以及包括主题、过期和发布时间等声明的有效载荷都转换为 JSON，然后进行 Base64URL 编码。然后，这些编码的结果与一个点连接，之后使用报头中指定的算法和密钥或私钥生成签名。此签名也是 Base64URL 编码的，从而产生最终的 JWT 字符串，该字符串以适合传输或存储的格式表示令牌。

解码 JWT 通过将 Base64URL 编码的标头和有效载荷转换回 JSON 来逆转这一过程，允许任何人在不需要密钥的情况下读取这些部分。然而，在这种情况下，“解码”通常会扩展到包括验证令牌的签名。此验证步骤涉及使用最初使用的相同算法和密钥对解码的报头和有效载荷进行重新签名，然后将此新签名与 JWT 中包含的签名进行比较。如果它们匹配，它将确认令牌的完整性和真实性，确保自发行以来没有被篡改。