JsonWebToken

March 18, 2022March 21, 2024

下文基本翻译自：https://jwt.io/introduction
另见： The JWT Handbook: https://jwt.surge.sh
JSON Web Token 入门教程：https://ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html

什么是 JSON Web Token？

JSON Web Token (JWT) 是一种开放标准 (RFC 7519)，它定义了一种紧凑且自包含的方式，可以以 JSON 对象的形式在各方之间安全地传输信息。这些信息可以得到验证和信任，因为它们是经过数字签名的。可以通过使用密钥（使用 HMAC 算法）或使用 RSA 或 ECDSA 的公钥/私钥对来对 JWT 进行签名。

尽管可以对 JWT 进行加密，以便在各方之间提供机密性，但我们重点关注签名令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌会向其他方隐藏这些声明。当使用公钥/私钥对对令牌签名时，签名还证明持有私钥的一方就是对其进行签名的一方。

你应该在何时使用 JSON Web Token？

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

**授权：**这是使用 JWT 最常见的场景。用户登录后，每个后续请求都将包含 JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是一种广泛使用 JWT 的功能，因为其开销小，而且可以轻松地用于不同的域中。
**信息交换：**JSON Web Token 是安全地在各方之间传输信息的好方法。由于可以对 JWT 进行签名（例如，使用公钥/私钥对），因此你可以确信发送者就是他们所说的那样。此外，由于签名是使用 Header 和有效负载计算的，因此你还可以验证内容是否未被篡改。

JSON Web Token 的结构是什么？

在紧凑形式中，JSON Web Token 由三个用点（.）分隔的部分组成，它们是：

Header
有效负载（Payload）
签名（Signature）

因此，一个 JWT 通常如下所示。

xxxxx.yyyyy.zzzzz

我们分解一下不同的部分。

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

例如：

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

然后，将此 JSON Base64Url 编码为 JWT 的第一部分。

有效负载

令牌的第二部分是有效负载，其中包含声明。声明是对实体（通常是用户）和附加数据的陈述。有三种类型的声明：已注册、公共和私有声明。

已注册声明（Registered claims）：这些是一组预定义的声明，它们不是强制性的，但建议使用，以提供一组有用的、可互操作的声明。其中一些声明为：iss（颁发者）、exp（到期时间）、sub（主题）、aud（受众），以及其它。

请注意，由于 JWT 的目的是紧凑，因此声明名称只有三个字符长。
公共声明（Public claims）：这些声明可以由使用 JWT 的人随意定义。但是，为了避免冲突，它们应在 IANA JSON Web Token Registry 中进行定义，或定义为包含防冲突命名空间的 URI。
私有声明（Private claims）：这些是创建的自定义声明，用于在同意使用它们且不是已注册或公共声明的各方之间共享信息。

一个示例有效负载可以是：

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

然后将有效负载 Base64Url 编码为 JSON Web Token 的第二部分。

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

签名

要创建签名部分，你必须获取编码 Header、编码有效负载、一个密钥、Header 中指定的算法，并对其进行签名。

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

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

签名用于验证消息不会在传输过程中被更改，并且，对于用私钥签名的令牌，它还可以验证 JWT 的发送方是否为其声称的身份。

可使用 HMAC 或 公钥/密钥对 算法进行签名。显然，HMAC 的 secret 就相当于公钥/密钥对的公钥+私钥
有关具体密钥算法，另见：密钥类型、算法和操作

Putting all together

输出是三个 Base64-URL 字符串，它们由点号分隔，可轻松地通过 HTML 和 HTTP 环境传递，而与基于 XML 的标准（例如 SAML）相比，其更紧凑。

下面显示了一个具有先前编码的 Header 和有效负载、并使用密钥进行签名的 JWT。编码的 JWT

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

JWT.io 调试器

JSON Web Token 如何工作？

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

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

每当用户想要访问受保护的路由或资源时，用户代理都应发送 JWT，通常是在 Authorization Header 中使用 Bearer 架构。Header 的内容应如下所示：

Authorization: Bearer <token>

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

请注意，如果你通过 HTTP Header 发送 JWT 令牌，你应尝试防止令牌变得太大。某些服务器不接受 Header 中超过 8 KB 的内容。如果你试图在 JWT 令牌中嵌入过多信息，例如此处包括了所有用户权限，则可能需要一种替代方案，例如 Auth0 细粒度授权。

如果令牌在 Authorization Header 中发送，那么跨源资源共享 (CORS) 不会成为问题，因为它不使用 cookie。

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

JSON Web Token 如何工作

应用程序或客户端向授权服务器请求授权。这是通过不同的授权流执行的。例如，一个典型的 OpenID Connect 兼容 Web 应用程序将使用授权码流经过 /oauth/authorize 端点。
当授予授权时，授权服务器向应用程序返回访问令牌。
应用程序使用访问令牌访问受保护的资源（如 API）。

请注意，对于已签名令牌，令牌中包含的所有信息都对用户或其他方公开，即使他们无法更改令牌也是如此。这意味着你不应在令牌中放入机密信息。

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

让我们讨论 JSON Web Token (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 Token 在多个平台（尤其是移动平台）上进行客户端处理的容易程度。

比较编码的 JWT 和编码的 SAML 的长度

如果你想详细了解 JSON Web Token，甚至开始使用它们在自己的应用程序中执行身份验证，请浏览 Okta 旗下的 Auth0 的 JSON Web Token 登陆页面。

←Back to home

This work is licensed under CC BY-NC-SA 4.0