3 种JWT验证和续签的策略
好文推荐：一文教你搞定所有前端鉴权与后端鉴权方案，让你不再迷惘 - 掘金 (juejin.cn)
3 种jwt 验证的策略
- 通过解析去验证：每次访问api时parse jwt 判断是否vaild
-
jwt有效
- 正常调用api
-
jwt无效
- 返回401
缺点：token只有过期才会失效。就算用户退出登录，token仍是有效的。（除非token过期时间很短）
- 在解析的基础上，添加多一层存储层（这里用redis）的判断：每次访问api时parse jwt 判断是否vaild，然后再看redis中是否存在该token。
用户退出登录的时候，需要使token失效（也就是，delete redis中的token）；
- 不解析（目的是更快地判断jwt是否有效）：将生成的token作为key（value可以是它的具体过期时间（用于refresh））存储在redis中，用户访问时，只要redis中存在该token就放行。用户login后需要同时存<uid,token>和<token,refreshTime>，因为需要去使token失效。
- 为什么要存多个<uid,token>？
- 假如一个坏人拿到了用户的token去续签，然后用户那个旧token是会被删掉的，然后用户登录的时候，因为token过期，就需要他重新登录，这个时候是需要将坏人续签的token在redis中删去的，如果只有token为key的键值对，我就找不到它并把它删掉。因此登录的时候存多一个<uid,token>就可以通过用户请求登录时候携带的uid去redis中获取到那个坏人续签的token值并删掉，这样起到一个顶替掉坏人的作用。
在redis中的过期时间设置为同jwt过期时间一样。
用户退出登录以及重新登录的时候，需要使旧token失效（也就是，delete redis中的<uid,token>和<token,refreshTime>）
第三种如图：
3 种jwt续签的策略
-
后端提供refresh token的接口，然后让前端自己调用refresh token的接口。用户login后返回token时，携带token应该refresh的时间戳。
-
用户login后，同时生成token和refresh token（过期时间很长）并一起返回给用户，由前端完成携带token的逻辑。
-
后端在验证jwt有效性后，判断如果快过期了，则生成refresh token，将redis中旧的jwt删去，将新的jwt放入redis，并与前端协商好状态码再返回，然后前端再用新的token重新发起原请求。
