JSON Web Tokens简介
JSON Web Tokens简介
JWT（JSON Web Token）是一种开放标准（RFC 7519），用于在各方之间安全地传输信息。它采用紧凑的JSON格式，通过数字签名确保信息的完整性和可信度。本文将详细介绍JWT的概念、结构、工作原理以及其在实际应用中的优势。
什么是 JSON Web Token?
JSON Web Token（JWT）是一种开放标准（RFC 7519），它定义了一种紧凑且独立的方式，用于在各方之间以JSON对象的形式安全地传输信息。此信息可以验证和信任，因为它是经过数字签名的。JWT可以使用密钥（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对进行签名。
尽管可以对JWT进行加密以在各方之间提供保密性，但我们将重点关注已签名的令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌可以向其他方隐藏这些声明。当使用公钥/私钥对对令牌进行签名时，签名还证明只有持有私钥的一方才是签名者。
什么时候应该使用JSON Web Tokens?
以下是JSON Web Tokens有用的一些场景：
授权: 这是使用JWT最常见的场景。用户登录后，每个后续请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是如今广泛使用JWT的一项功能，因为它的开销很小并且能够轻松跨不同域使用。
信息交换: JSON Web Tokens是在各方之间安全传输信息的好方法。因为JWT可以签名——例如，使用公钥/私钥对——你可以确定发送者是他们所说的人。此外，由于签名是使用标头和有效负载计算的，因此你还可以验证内容是否未被篡改。
什么是 JSON Web Token 结构?
在其紧凑的格式中，JSON Web Tokens由三部分组成，由点（.）分隔，它们是：
- Header（标头）
- Payload（有效载荷）
- Signature（签名）
因此，JWT通常如下所示：
xxxxx.yyyyy.zzzzz
让我们分解不同的部分。
Header
标头通常由两部分组成：令牌的类型，即JWT，以及所使用的签名算法，例如HMAC SHA256或RSA。
例如：
{
"alg": "HS256",
"typ": "JWT"
}
然后，这个JSON被Base64Url编码以形成JWT的第一部分。
Payload
令牌的第二部分是有效负载，其中包含声明。声明是关于实体（通常是用户）和附加数据的声明。声明分为三种类型：registered（注册声明）、public（公共声明）和private（私人声明）。
- 已注册声明: 这些是一组预定义的声明，它们不是强制性的，但建议使用，以提供一组有用的、可互操作的声明。其中一些是：iss（发布者）、exp（到期时间）、sub（主题）、aud（受众）和其他。
请注意，声明名称只有三个字符长，因为JWT是为紧凑设计的。
公共声明: 这些可以由使用JWT的人随意定义。但是为了避免冲突，它们应该在IANA JSON Web Token注册表中定义，或者定义为包含抗冲突名称空间的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 Debugger来解码、验证和生成JWT。
JSON Web Tokens 如何工作?
在身份验证中，当用户使用其凭据成功登录时，将返回一个JSON Web Token。由于令牌是凭据，因此必须非常小心以防止出现安全问题。通常，你不应将令牌保留的时间超过要求的时间。
由于缺乏安全性，你也不应该将敏感的会话数据存储在浏览器存储中。
每当用户想要访问受保护的路由或资源时，用户代理都应发送JWT，通常在使用Bearer模式的Authorization标头中。标头的内容应如下所示：
Authorization: Bearer <token>
在某些情况下，这可以是无状态授权机制。服务器的受保护路由将在Authorization标头中检查有效的JWT，如果存在，则允许用户访问受保护的资源。如果JWT包含必要的数据，则可能会减少为某些操作查询数据库的需要，尽管情况可能并非总是如此。
请注意，如果你通过HTTP标头发送JWT令牌，则应尝试防止它们变得太大。某些服务器不接受超过8KB的标头。如果尝试在JWT令牌中嵌入过多信息（例如包含所有用户的权限），则可能需要替代解决方案，例如Auth0细粒度授权。
如果令牌在Authorization标头中发送，跨源资源共享(CORS)将不会成为问题，因为它不使用cookie。
下图显示了如何获取JWT并将其用于访问API或资源：
应用程序或客户端向授权服务器请求授权。这是通过不同的授权流之一执行的。例如，典型的OpenID Connect兼容Web应用程序将使用授权代码流通过/oauth/authorize端点。
授予授权后，授权服务器会向应用程序返回一个访问令牌。
应用程序使用访问令牌访问受保护的资源（如API）。
请注意，对于已签名的令牌，令牌中包含的所有信息都会暴露给用户或其他方，即使他们无法更改。这意味着你不应将秘密信息放入令牌中。
我们为什么要使用JSON Web Tokens?
让我们谈谈JSON Web Tokens (JWT)与Simple Web Tokens (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 Tokens的更多信息，甚至开始使用它们在你自己的应用程序中执行身份验证，请浏览Auth0上的JSON Web Token页面。