官方文档: https://jwt.io/introduction
什么是 JSON Web Token?
JSON Web 令牌 (JWT) 是一种开放标准 (RFC 7519),它定义了一种紧凑且自包含的方式,用于在各方之间安全地传输信息作为 JSON 对象。此信息可以进行验证和信任,因为它是经过数字签名的。可以使用密钥(使用 HMAC 算法)或使用 RSA 或 ECDSA 对公钥/私钥对对 JWT 进行签名。
虽然JWT可以加密以在各方之间提供保密性,但我们将专注于签名令牌。签名令牌可以验证其中包含的声明的完整性,而加密令牌则对其他方隐藏这些声明。当使用公钥/私钥对对对令牌进行签名时,签名还会证明只有持有私钥的一方才是签名的一方。
何时应使用 JSON Web 令牌?
以下是 JSON Web 令牌有用的一些方案:
- 授权:这是使用 JWT 的最常见方案。用户登录后,每个后续请求都将包含 JWT,允许用户访问该令牌允许的路由、服务和资源。单点登录是当今广泛使用 JWT 的一项功能,因为它的开销很小,并且能够跨不同域轻松使用。
信息交换:JSON Web令牌是在各方之间安全传输信息的好方法。由于可以对 JWT 进行签名(例如,使用公钥/私钥对),因此您可以确定发件人是他们所说的发件人。此外,由于签名是使用标头和负载计算的,因此您还可以验证内容是否未被篡改。
什么是 JSON Web 令牌结构?
在其紧凑的形式中,JSON Web令牌由三部分组成,由点()分隔,它们是:.
页眉
- 有效载荷
- 签名
因此,JWT 通常如下所示。
xxxxx.yyyyy.zzzzz
让我们分解不同的部分。
页眉
标头通常由两部分组成:令牌的类型(即 JWT)和正在使用的签名算法(如 HMAC SHA256 或 RSA)。
例如:
{ “alg”: “HS256”, “typ”: “JWT” }
然后,此 JSON 进行 Base64Url 编码以形成 JWT 的第一部分。
有效载荷
令牌的第二部分是有效负载,其中包含声明。声明是关于实体(通常是用户)和其他数据的语句。有三种类型的声明:已注册声明、公共声明和私人声明。
- 已注册的声明:这些是一组预定义的声明,这些声明不是必需的,但建议使用,以提供一组有用的、可互操作的声明。其中一些是:iss(发行人),exp(到期时间),子(主题),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,它对以前的标头和有效负载进行了编码,并且使用机密对其进行了签名。
如果要使用 JWT 并将这些概念付诸实践,可以使用调试器 jwt.io 解码、验证和生成 JWT。
JSON Web 令牌如何工作?
在身份验证中,当用户使用其凭据成功登录时,将返回 JSON Web 令牌。由于令牌是凭据,因此必须格外小心以防止安全问题。通常,令牌的保留时间不应超过所需的时间。
由于缺乏安全性,您也不应将敏感会话数据存储在浏览器存储中。
每当用户想要访问受保护的路由或资源时,用户代理都应发送 JWT,通常在授权标头中使用持有者架构。标头的内容应如下所示:
Authorization: Bearer
在某些情况下,这可以是无状态授权机制。服务器的受保护路由将检查标头中的有效 JWT,如果存在,则允许用户访问受保护的资源。如果 JWT 包含必要的数据,则查询数据库以获取某些操作的需要可能会减少,尽管情况可能并非总是如此。Authorization
请注意,如果通过 HTTP 标头发送 JWT 令牌,则应尝试防止它们变得太大。某些服务器不接受超过 8 KB 的标头。如果尝试在 JWT 令牌中嵌入太多信息(例如,通过包含所有用户的权限),则可能需要替代解决方案,如 Auth0 细粒度授权。
如果令牌在标头中发送,则跨源资源共享 (CORS) 不会成为问题,因为它不使用 Cookie。Authorization
下图显示了如何获取 JWT 并用于访问 API 或资源:
- 应用程序或客户端向授权服务器请求授权。这是通过一个不同的授权流执行的。例如,典型的 OpenID Connect 兼容 Web 应用程序将使用授权代码流通过终结点。/oauth/authorize
- 授予授权后,授权服务器将向应用程序返回访问令牌。
- 应用程序使用访问令牌访问受保护的资源(如 API)。
请注意,使用签名令牌时,令牌中包含的所有信息都会向用户或其他方公开,即使他们无法更改它。这意味着您不应将机密信息放在令牌中。
我们为什么要使用JSON Web Token?
让我们来谈谈 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 令牌进行客户端处理的便利性。
编码的 JWT 和编码的 SAML 的长度比较
如果您想了解有关 JSON Web 令牌的更多信息,甚至开始使用它们在您自己的应用程序中执行身份验证,请浏览到 Auth0 上的 JSON Web 令牌登录页面。
