之前在第一篇中提到过其使用流程，以下讲的是第二种：https://blog.csdn.net/qq_37534947/article/details/132066909
但是JWT主要作用应该应用于以下：作为在前后端分离项目中的登录策略，这个过程其实包含了“单纯作为客户端的请求身份认证，spring-gateway网关进行判断拦截”这一部分。

1、前后端使用JWT详细步骤

• 客户端登录，后端服务生成JWT字符串
• 后端服务将JWT字符串保存到Cookie中返回给客户端
• 客户端再次发送其它请求（非登录请求），cookie携带JWT字符串
• 后端接收到请求，首先解析JWT字符串，如果通过在响应请求，否则直接拒绝请求

2、前后端使用JWT详情图

-

3、从流程中看优点与缺点

3.1 优点

• 客户端请求不依赖服务端的信息，多次请求不需要必须访问到同一台服务器。
• 减小服务端存储压力。
• 基于JSON，方便解析，可以在令牌中自定义丰富内容，易扩展。
• 通过非对称加密及数字签名技术，可以防止篡改、安全性高。可以不依赖认证服务就可以完成授权。

3.2 缺点

• 无法满足注销场景

  传统的 session+cookie 方案用户点击注销，服务端清空 session 即可，因为状态保存在服务端。但 jwt 的方案就比较难办了，因为 jwt 是无状态的，服务端通过计算来校验有效性。没有存储起来，所以即使客户端删除了 jwt，但是该 jwt 还是在有效期内，只不过处于一个游离状态。

• 无法满足修改密码场景

  修改密码则略微有些不同，假设号被到了，修改密码（是用户密码，不是 jwt 的 secret）之后，盗号者在原 jwt 有效期之内依旧可以继续访问系统，所以仅仅清空 cookie 自然是不够的，这时，需要强制性的修改 secret。

• 无法满足token续签场景
  我们知道微信只要你每天使用是不需要重新登录的，因为有token续签，因为传统的 cookie 续签方案一般都是框架自带的，session 有效期 30 分钟，30 分钟内如果有访问，session 有效期被刷新至 30 分钟。但是 jwt 本身的 payload 之中也有一个 exp 过期时间参数，来代表一个 jwt 的时效性，而 jwt 想延期这个 exp 就有点身不由己了，因为 payload 是参与签名的，一旦过期时间被修改，整个 jwt 串就变了，jwt 的特性天然不支持续签！