JWT 中文官方文档

官方文档
官方文档
官方文档

什么是 JSON Web Token？

JSON Web 令牌 （JWT） 是一种开放标准 （RFC 7519），它定义了一种紧凑且独立的方式，用于在各方之间以 JSON 对象的形式安全地传输信息。此信息可以验证和信任，因为它是经过数字签名的。JWT 可以使用密钥（使用 HMAC 算法）或使用 RSA 或 ECDSA 的公钥/私钥对进行签名。

尽管 JWT 可以加密以提供各方之间的保密性，但我们将专注于签名令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌则向其他方隐藏这些声明。当使用公钥/私钥对对令牌进行签名时，签名还证明只有持有私钥的一方才是签名的一方。

何时应使用 JSON Web 令牌？

以下是 JSON Web 令牌有用的一些方案：

• 授权：这是使用 JWT 的最常见方案。用户登录后，每个后续请求都将包含 JWT，允许用户访问使用该令牌允许的路由、服务和资源。单点登录是当今广泛使用 JWT 的一项功能，因为它的开销很小，并且能够跨不同域轻松使用。
• 信息交换：JSON Web 令牌是在各方之间安全传输信息的好方法。由于 JWT 可以签名（例如，使用公钥/私钥对），因此您可以确定发件人是他们所说的人。此外，由于签名是使用标头和有效负载计算的，因此您还可以验证内容是否未被篡改。

什么是 JSON Web 令牌结构？

JSON Web 令牌的紧凑形式由由点 （） 分隔的三个部分组成，分别是：.

• 页眉(header)
• 载荷(payload)
• 签名(sign)

因此，JWT 通常如下所示。

xxxxx.yyyyy.zzzzz

让我们分解不同的部分。

页眉
标头通常由两部分组成：令牌的类型（即 JWT）和正在使用的签名算法，例如 HMAC SHA256 或 RSA。
例如：

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

然后，此JSON被Base64Url编码以形成JWT的第一部分。

有效载荷
令牌的第二部分是有效负载，其中包含声明。声明是有关实体（通常是用户）和其他数据的语句。 有三种类型的声明：已注册、公共和私人声明。

• 已注册声明：这些是一组预定义的声明，这些声明不是必需的，但建议使用，以提供一组有用的、可互操作的声明。其中一些是：iss（发行人），exp（到期时间），sub（主题），aud（受众）等。

请注意，声明名称只有三个字符长，因为 JWT 应该是紧凑的。

• 公共声明：这些可以由使用 JWT 的人随意定义。但为了避免冲突，它们应该在 IANA JSON Web 令牌注册表中定义，或者定义为包含抗冲突命名空间的 URI。

• 专用声明：这些是创建的自定义声明，用于在同意使用它们的各方之间共享信息，既不是注册声明也不是公共声明。

示例有效负载可以是：

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

然后对有效负载进行 Base64Url 编码以形成 JSON Web 令牌的第二部分。

请注意，对于签名令牌，此信息虽然受到篡改保护，但任何人都可以读取。不要将机密信息放在 JWT 的有效负载或标头元素中，除非它已加密。

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

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

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

签名用于验证消息在此过程中未被更改，并且在使用私钥签名的令牌的情况下，它还可以验证 JWT 的发件人是否是它所说的人。

把所有东西放在一起
输出是三个由点分隔的 Base64-URL 字符串，可以在 HTML 和 HTTP 环境中轻松传递，同时与基于 XML 的标准（如 SAML）相比更加紧凑。

下面显示了对以前的标头和有效负载进行了编码并使用机密进行签名的 JWT。Encoded JWT

如果要使用 JWT 并将这些概念付诸实践，可以使用调试器 jwt.io 解码、验证和生成 JWT。
JWT.io Debugger

JSON Web 令牌如何工作？

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

由于缺乏安全性，您也不应将敏感的会话数据存储在浏览器存储中。

每当用户想要访问受保护的路由或资源时，用户代理都应发送 JWT，通常在使用持有者架构的授权标头中发送。标头的内容应如下所示：

Authorization: Bearer <token>

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

请注意，如果您通过 HTTP 标头发送 JWT 令牌，则应尝试防止它们变得太大。某些服务器不接受超过 8 KB 的标头。如果尝试在 JWT 令牌中嵌入过多信息（例如包含所有用户的权限），则可能需要替代解决方案，例如 Auth0 细粒度授权。

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

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

1. 应用程序或客户端向授权服务器请求授权。这是通过不同的授权流之一执行的。例如，典型的符合 OpenID Connect 的 Web 应用程序将使用授权代码流通过端点。/oauth/authorize
2. 授予授权后，授权服务器将向应用程序返回访问令牌。
3. 应用程序使用访问令牌访问受保护的资源（如 API）。

请注意，使用签名令牌时，令牌中包含的所有信息都会向用户或其他方公开，即使他们无法更改它。这意味着您不应将机密信息放在令牌中。

为什么我们应该使用 JSON Web 令牌？

让我们谈谈JSON Web 令牌 （JWT） 与简单 Web 令牌 （SWT） 和安全断言标记语言令牌 （SAML） 相比的优势。

由于JSON不如XML那么冗长，因此在编码时其大小也更小，这使得JWT比SAML更紧凑。这使得 JWT 成为在 HTML 和 HTTP 环境中传递的不错选择。

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

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

关于使用，JWT以互联网规模使用。这突出了在多个平台（尤其是移动设备）上对 JSON Web 令牌进行客户端处理的便利性。

Comparing the length of an encoded JWT and an encoded SAML 编码 JWT 和编码 SAML 的长度比较

如果您想了解有关 JSON Web 令牌的更多信息，甚至开始使用它们在您自己的应用程序中执行身份验证，请浏览到 Auth0 上的 JSON Web 令牌登录页面。