原文地址：https://jwt.io/introduction/
JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各程序之间以JSON对象方式安全地传输信息。由于此信息是经过数字签名的，因此可以被验证和信任。可以使用加密算法（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对对JWT进行签名。
尽管JWTs可以被加密以在双方之间提供保密性，但我们将重点关注已签名的令牌。签名的令牌可以验证其中包含的claims 的完整性，而加密的令牌则将这些claims 隐藏了。当使用公钥/私钥对token进行签名时，签名还证明只有持有私钥的一方才是对其进行签名的一方。
以下是JSON Web Token使用场景：
Authorization（授权）：这是使用JWT最常见的场景。一旦用户登录，后续的每一个请求将附带JWT，从而允许用户访问该token允许的路由，服务和资源。单点登录是当今广泛使用JWT的一个特性，因为它的开销很小并且可以在不同的域中轻松使用。
信息交换：JSON Web Token是在各程序之间安全地传输信息的好方法。因为可以对JWT进行Signature（例如，使用公钥/私钥），所以您可以确定发件人是他本人。另外，由于Signature是使用header和payload计算出来的，因此您还可以验证内容是否未被篡改。
JSON Web Token以紧凑的形式由三部分组成，这些部分由点（.）分隔，分别是：
因此，JWT通常如下所示。
xxxxx.yyyyy.zzzzz
让我们分解不同部分。
header通常由两部分组成：token的类型（JWT）和所使用的签名算法，例如HMAC SHA256或RSA。
例如：
{
"alg": "HS256",
"typ": "JWT"
}
然后，此JSON通过Base64Url编码作为JWT的第一部分。
token的第二部分是payload，其中包含claims。claims是有关实体（通常是用户）和其他数据的claims。claims有以下三种类型：registered, public, 和 private claims。
registered claims：这些是一组非强制性的但建议使用的预定义claims，以提供一组有用的，可互操作的claims。其中一些是： iss（发出者）， exp（到期时间）， sub（主题）， aud（受众）。
请注意，声明名称仅是三个字符，因为JWT是紧凑的。
public claims：使用JWT的人可以随意定义这些claims。但是为避免冲突，应在 IANA JSON Web令牌注册表中定义它们，或将其定义为包含避免冲突名称空间的URI。
private claims：这些自定义claims是为在同意使用这些声明的各方之间共享信息而创建的，它们既不是注册声明，也不是公开声明。
payload示例可能是：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后，对payload进行Base64Url编码，作为JSON Web令牌的第二部分。
请注意，对于已签名的token，此信息尽管可以防止篡改，但任何人都可以读取。除非将其加密，否则请勿将机密信息放入JWT的payload或header元素中。
要创建signature部分，您必须获取编码的header，编码的payload，secret，header中指定的算法，并对其进行签名。
例如，如果要使用HMAC SHA256算法，则将通过以下方式创建签名：
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
signature用于验证消息在整个过程中没有更改，并且对于使用私钥进行签名的token，它还可以验证JWT的发送者是它所说的真实身份。
输出是三个由点分隔的Base64-URL字符串，可以在HTML和HTTP环境中轻松传递这些字符串，与基于XML的标准（例如SAML）相比，它更紧凑。
下图显示了一个JWT，它已对先前的header和payload进行了编码，并用一个secret进行了签名。 
如果您想使用JWT并将这些概念付诸实践，则可以使用jwt.io Debugger解码，验证和生成JWT。
在身份验证中，当用户使用其凭据成功登录时，将返回JSON Web Token。由于token是凭据，因此必须格外小心以防止安全问题。通常，令牌的保留时间不应超过要求的时间。
每当用户想要访问受保护的路由或资源时，用户代理通常应在Bearer模式中使用授权头发送JWT 。标头的内容应如下所示：
Authorization: Bearer <token>
在某些情况下，这可以是无状态授权机制。服务器的受保护路由将在Authorization标头中检查有效的JWT ，如果存在，则将允许用户访问受保护的资源。如果JWT包含必要的数据，则可以减少查询数据库中某些操作的需求，尽管这种情况并非总是如此。
如果token是在Authorization标头中发送的，则跨域资源共享（CORS）不会成为问题，因为它不使用cookie。
下图显示了如何获取JWT并将其用于访问API或资源：
/oauth/authorize使用授权代码流通过端点。请注意，使用签名token，token或token中包含的所有信息都会暴露给用户或其他方，即使他们无法更改它。这意味着您不应将机密信息放入token中。
让我们谈谈与简单Web Token（SWT）和安全性声明标记语言令牌（SAML）相比，JSON Web Token（JWT）的好处。
由于JSON不如XML冗长，因此在编码时JSON的大小也较小，从而使JWT比SAML更紧凑。这使得JWT是在HTML和HTTP环境中传递的不错的选择。
在安全方面，只能使用HMAC算法由共享机密对SWT进行对称签名。但是，JWT和SAML令牌可以使用X.509证书形式的公用/专用密钥对进行签名。与签名JSON的简单性相比，使用XML Digital Signature签名XML而不引入模糊的安全漏洞是非常困难的。
JSON解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反，XML没有自然的文档到对象映射。与SAML断言相比，这使使用JWT更加容易。
关于用法，JWT是在Internet规模上使用的。这强调了在多个平台（尤其是移动平台）上对JSON Web令牌进行客户端处理的简便性。
编码的JWT和编码的SAML的长度比较
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。