JWT详细介绍

什么是 JSON Web Token？

JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间安全地传输信息作为 JSON 对象。这些信息可以被验证和信任，因为它们是数字签名的。JWT 可以使用秘密（使用 HMAC 算法）或公钥/私钥对（使用 RSA 或 ECDSA）进行签名。虽然 JWT 可以加密以提供各方之间的保密性，但我们将重点关注 已签名 的令牌。已签名的令牌可以验证其中包含的声明的 完整性，而加密的令牌则会将这些声明隐藏起来，不让其他方看到。当使用公钥/私钥对对令牌进行签名时，签名还证明只有持有私钥的一方才是签署它的一方。

何时应该使用 JSON Web Token？

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

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

JSON Web Token 结构是什么？

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

头部
有效载荷
签名

因此，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 并将这些概念付诸实践，可以使用 jwt.io 调试器对 JWT 进行解码、验证和生成。

JSON Web Tokens是如何工作的？

在身份验证中，当用户使用其凭据成功登录时，将返回JSON Web Token。由于令牌是凭据，因此必须非常小心地防止安全问题。通常情况下，您不应将令牌保存的时间超过所需时间。您也不应将敏感的会话数据存储在浏览器存储中，因为缺乏安全性。每当用户想要访问受保护的路由或资源时，用户代理应该发送JWT，通常在Authorization标头中使用Bearer模式。标头的内容应如下所示：

Authorization: Bearer <token>

在某些情况下，这可以是无状态授权机制。服务器的受保护路由将检查Authorization标头中是否有有效的JWT，如果存在，则允许用户访问受保护的资源。如果JWT包含必要的数据，则可以减少查询数据库以进行某些操作的需要，尽管这并不总是适用的。请注意，如果您通过HTTP标头发送JWT令牌，应尽量防止它们变得过大。某些服务器不接受超过8 KB的标头。如果您尝试在JWT令牌中嵌入过多的信息，例如包括所有用户的权限，则可能需要另一种解决方案，例如Auth0细粒度授权。如果令牌在Authorization标头中发送，则跨域资源共享（CORS）不会成为问题，因为它不使用cookie。以下图表显示了如何获取JWT并用于访问API或资源： JSON Web Token的工作原理

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

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

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

让我们谈谈JSON Web Tokens（JWT） 与Simple Web Tokens（SWT） 和Security Assertion Markup Language Tokens（SAML） 相比的好处。由于JSON比XML更简洁，因此在编码时其大小也更小，使得JWT比SAML更紧凑。这使得JWT成为在HTML和HTTP环境中传递的良好选择。从安全性方面来看，SWT只能使用HMAC算法使用共享密钥进行对称签名。但是，JWT和SAML令牌可以使用公钥/私钥对形式的X.509证书进行签名。与使用XML数字签名签名XML而不引入模糊的安全漏洞相比，使用JSON进行签名的简单性要高得多。大多数编程语言中都有常见的JSON解析器，因为它们直接映射到对象。相反，XML没有自然的文档到对象映射。这使得使用JWT比使用SAML断言更容易。关于使用，JWT在互联网规模上使用。这突显了在多个平台上轻松进行客户端处理JSON Web令牌的便利性，特别是移动设备。 编码JWT和编码SAML的长度比较 如果您想了解更多关于JSON Web Tokens的信息，甚至开始在自己的应用程序中使用它们进行身份验证，请浏览Auth0的JSON Web Token着陆页。

本文来源：https://jwt.io/introduction