JWT(Json Web Token)介绍

什么是JWT？

JSON Web Token （JWT）是一个开放式标准（RFC 7519），它定义了一种紧凑且自成一体的方式，用于将各方之间的信息安全传输为 JSON 对象。此信息可以验证和信任，因为它是数字签名的。JWT 可以使用秘密（使用HMAC算法）或使用RSA或ECDSA的公/私密密钥对进行签名。

我们为什么要用JWT？

与简单的 Web 令牌（SWT）和安全断言标记语言令牌（SAML）相比，让我们来谈谈 JSON Web 令牌（JWT）的好处。

由于 JSON 比 XML 更冗长，因此在编码时，其大小也更小，使 JWT 比 SAML 更紧凑。这使得 JWT 成为在 HTML 和 HTTP 环境中传递的一个不错的选择。
在安全性方面，SWT 只能通过使用 HMAC 算法的共享密秘密进行对称签名。但是，JWT 和 SAML 令牌可以使用以 X.509 证书形式形式的公共/私人密钥对进行签名。与签署 JSON 的简单性相比，在不引入模糊安全漏洞的情况下使用 XML 数字签名是非常困难的。
JSON 解析器在大多数编程语言中很常见，因为它们直接映射到对象。相反，XML 没有自然的文档对对象映射。这使得与 JWT 合作比 SAML 断言更容易。
在使用方面，JWT 在互联网规模上使用。这突出了在多个平台（尤其是移动平台）上对 JSON Web 令牌进行客户端处理的便利性。

JWT的构成

Header 头部

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

例如：
```
{
"alg": "HS256",
"typ": "JWT"
}
```
‎然后，此 JSON 是‎‎Base64Url‎‎编码，以形成 JWT 的第一部分。‎
Payload 负载 (类似于飞机上承载的物品)

令牌的第二部分是有效载荷，其中包含有效信息。有效信息包含三个部分：
- 注册的声明（建议但不强制使用）：
```
iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间，这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。
```
- 公共的声明：
公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.
- 私有的声明：
这些是为在同意使用它们的各方之间共享信息而创建的自定义声明，既不是注册的声明，也不是公共的声明。

例如：
```
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
```
‎然后，对有效载荷‎‎进行 Base64Url‎‎编码，以形成 JSON Web 令牌的第二部分。‎
```
ewogICJzdWIiOiAiMTIzNDU2Nzg5MCIsCiAgIm5hbWUiOiAiSm9obiBEb2UiLAogICJhZG1pbiI6IHRydWUKfQ==
```
Signature 签名/签证

令牌的第三部分是签名，要创建签名，必须使用Base64Url‎编码后的Header头部、Base64Url‎编码后的Payload 载荷和一个secret（盐），Header头部和Payload 载荷使用.连接组成的字符串，通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

‎例如，如果您想要使用 HMAC SHA256 算法，则会以以下方式创建签名：‎
```
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
```
签名用于验证信息，在途中没有更改，并且对于使用私人密钥签名的令牌，还可以验证 JWT 的发送者是否为其所声明的发送者。

注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。