在项目里面，实现登录认证有很多方式，其中传统的session和jwt应该是主要的两种，通过对比我们来揭开jwt的神秘面纱。
基于传统session的缺点如下：
服务端要保存大量的session数据，增加了访问压力
如果要做集群化部署，那么服务器要把session做共享，十分麻烦
jwt认证克服了session的弊端，它不需要在服务器里面保存大量的信息，这也意味着如果有多台服务器，也不需要考虑用户在哪台服务器访问认证。
基于jwt的认证流程：
用户发请求传用户名和密码；服务器验证用户信息；验证通过后发送用户一个token；客户端存储token，下次用户发请求都要携带这个token服务端接受并解析token，如果解析正确，则放行用户请求，给他服务或者数据 JWT包含三段信息，每段信息之间用.拼接，实际上就是三段信息拼接的字符串，具体样子如下
可以看到由三个字符串拼接为一个长字符串，这就是jwt的数据格式。下面就一一解读下这三段信息。
1.头部Header（第一段字符串）
头部通常包含两个信息，格式如下：
{ 'typ': 'JWT', 'alg': 'HS256' } typ 声明类型，alg声明加密的算法，将上述格式的数据通过Base64Url编码（可解码）就得到了第一段字符串：eyJhbGciOiJIUzUxMiJ9
2.载荷payload（第二段字符串）
载荷就是存放有效数据，通常存放三部分有效信息，标准中注册的声明、公共的声明、私有的声明。
关于标准中注册的声明，官方文档中给出了七个示例信息：
iss (issuer)：表示签发人exp (expiration time)：表示token过期时间sub (subject)：主题aud (audience)：受众nbf (Not Before)：生效时间iat (Issued At)：签发时间jti (JWT ID)：编号 关于公共声明，它就是可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密。
关于私有的声明 ，私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。
我们可以自定义一个payload：
{ "userId":15, "userName":"dream_coke1" } 通过base64编码后就变成了第二段字符串：eyJ1c2VyTmFtZSI6ImRyZWFtX2Nva2UxIiwidXNlcklkIjo3fQ
3.签名 Signature：是整个数据的认证信息，那么它是怎么得到的呢？通过前面两个步骤，我们可以得到经过base64编码后的第一部分和第二部分的字符串，那么这个字符串再加上密钥secret（密钥（也是一段字符串）保存在服务端，不能泄露给客户端），通过 Header 中配置的加密算法（这里是HS256）生成.故最后生成了第三段字符串jxgP52fFp1PIjR6BjPd4cq5Je2lq_w_95ylsxe7HiSxvbXPpYmC7iXVy1gj-4WjOr8176pjG–EuhcTiiUmrIA
详情见下面的链接
https://blog.csdn.net/dream_cola/article/details/109205068
待更新
