JWT组成结构

1.令牌组成

• 1.标头(Header)
• 2.有效载荷(Payload)
• 3.签名(Signature)
• 因此，JWT通常如下所示:xxxxx.yyyyy.zzzzz Header.Payload.Signature

2. Header

• 标头通常由两部分组成：令牌的类型（即JWT）和所使用的签名算法，例如HMAC SHA256或RSA。它会使用 Base64 编码组成 JWT 结构的第一部分。

• 注意:Base64是一种编码，也就是说，它是可以被翻译回原来的样子来的。它并不是一种加密过程。

// typ =》 type 类型，省略 e ，减小数据大小
// algorithm =》 算法
{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload 有效负载

• 令牌的第二部分是有效负载，其中包含声明。声明是有关实体 ，用户相关信息，类似 principal

• （通常是用户）和其他数据的声明。同样的，它会使用 Base64 编码组成 JWT 结构的第二部分

注意：敏感信息不能放入 payload，比如 密码，因为保存在客户端，还是会有被窃取的风险的

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

3. Signature 签名

其实就是  算法 HS256（Base64（header + payload），secret私钥）=》Siganture签名，绝对不能泄露，不然的话，你的 token 就不安全了，会被攻击服务器

如果是公钥的话，算法 HS256（Base64（header + payload），随机盐salt + 公钥）=》Siganture签名， 重点就在 随机盐

• 前面两部分都是使用 Base64 进行编码的，即前端可以解开知道里面的信息。Signature 需要使用编码后的 header 和 payload 以及我们提供的一个密钥，然后使用 header 中指定的签名算法（默认HS256）进行签名。签名的作用是保证 JWT 没有被篡改过

• 如:

  HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret);

JWT校验

如果，服务器通过前端传递的 JWT 的前两部分，header、payload，通过 算法 HS256（Base64（header + payload），secret私钥） 计算出来的 Signature 签名和 前端传递的 JWT 的 Signature 签名一致的话，就代表验证通过

私钥。只能保存在 安全的硬件设备、云服务提供商的密钥管理服务、本地计算机上的密钥库（做小项目的时候，通常直接生成放到 项目中）

签名目的

• 最后一步签名的过程，实际上是对头部以及负载内容进行签名，防止内容被窜改。如果有人对头部以及负载的内容解码之后进行修改，再进行编码，最后加上之前的签名组合形成新的JWT的话，那么服务器端会判断（通过算法和密钥计算）出新的头部和负载形成的签名和前端传递过来的JWT附带上的签名是不一样的。如果要对新的头部和负载进行签名，在不知道服务器加密时用的密钥的话，得出来的签名也是不一样的。

信息安全问题

• 在这里大家一定会问一个问题：Base64是一种编码，是可逆的，那么我的信息不就被暴露了吗？

• 是的。所以，在JWT中，不应该在负载里面加入任何敏感的数据。在上面的例子中，我们传输的是用户的User ID。这个值实际上不是什么敏感内容，一般情况下被知道也是安全的。但是像密码这样的内容就不能被放在JWT中了。如果将用户的密码放在了JWT中，那么怀有恶意的第 三方通过Base64解码就能很快地知道你的密码了。因此JWT适合用于向Web应用传递一些非敏感信息。JWT还经常用于设计用户认证和授权系统，甚至实现Web应用的单点登录。

4. 令牌样式

三者放在一起

• 输出是三个由点分隔的Base64-URL字符串，可以在HTML和HTTP环境中轻松传递这些字符串，与基于XML的标准（例如SAML）相比，它更紧凑。

• 简洁(Compact)

  可以通过URL, POST 参数或者在 HTTP header 发送，因为数据量小，传输速度快

• 自包含(Self-contained)

  负载中包含了所有用户所需要的信息，避免了多次查询数据库

参考文章：https://blog.csdn.net/QGhurt/article/details/108192377