基于token的签发和验证衍生出的刷新和作废，有人说JWT不适合用于替换传统的 session+cookies 机制用于Web应用的用户登录状态维护，很大原因就是这块问题。

虽然之前的案例里面，我们可以成功在登录后获取一个Token，然后访问服务器的时候带着这个Token，服务器就可以知道当前访问的用户Uid了，假设现在有一下需求：

• 登录后7天不用重复登录
• 超过30天没有访问网站则需重新登录，否则一直有效
• 修改密码功能

Token续签问题

对于第一个问题，我们可以在jwt的 Payload 里面设置一个过期时间，比如说7天，超过这个时间Token无效。但是如果只是简单的这么做的话就会带来另一个问题： 假如一个用户正在访问网站，突然Token失效了，用户就会掉登录，体验太差。

所以，大部分时候我们都是采用第二种策略: 超过xx天不访问网站则需要重新登录，如果中间连续访问网站的话则不要重新登录，对于很多手机App，我们可不希望用户天天输账号密码登录，但如果永久有效可能会带来一些安全问题。

这其实就是Token的续签问题，我们看一下网上提到的一些解决方案：

1.更新Payload里面的过期时间。

JWT的Payload里面可以设置一个过期时间，我们可以在用户每次访问的时候把这个过期时间更新一下。由于JWT的secret加密机制，只要exp变了，整个Token就变了，所以这种机制相当于每次重新颁发了一个新的Token。

这种方案简单粗暴，存在性能问题。

2.快过期的时候更新Token

比如说离过期时间还有不到1个小时的时候才更新Token，性能上面可能好一点，但是如果一个用户一直在访问，但是恰好最后一个1个小时内没有访问网站，那岂不是也gg了？

那么可以考虑如下设计：
Token过期时间越短越安全，如设置Token过期时间15分钟，建议更换时间设置为Token前5分钟，则Token生命周期如下：

3.使用Cache记录Token过期时间

Token本身不设置过期时间，然后我们在redis或memcached等缓存里面单独设置一个有效期，每次访问的时候刷新过期时间。

其实这个方案和使用session机制无异，session也可以保存在redis或者memcached里面的。所以，有人戏说这是重新发明了session 。。。

4.使用refreshToken

借鉴 oauth2 的设计，返回给客户端一个 refreshToken，允许客户端主动刷新JWT。一般而言，jwt 的过期时间可以设置为数小时，而 refreshToken 的过期时间设置为数天。

前端解码token。拿到过期时间，和当前时间进行判断。如果快过期，主动调用获取新token.
缺点：前端每次请求需要解码判断
优点：后端压力小，不需要存储。

5.其它方案

最后说一下我觉得比较合适的方案，当服务器接受到一个Token后，如果它已经过期，但是已过期的时间在xx天内，比如说30天，我们就返回一个新的Token。比如说Token的有效期是7天，但是如果过期时间不超过30天就可以用旧的Token换取一个新的Token，如果超过了30天那就需要重新登录。

Token作废问题

当用户退出登录、修改密码之后，讲道理我们是需要作废之前的Token，比如说用户的Token被盗用了，只能通过修改密码来防止账号被盗用。如果使用session机制就很简单了，我们清空服务器session，或者使用新的session替换之前旧的session也行。

由于Token是无状态的，理论上只要不过期就可以一直用，你说这咋办？为了安全，必须得做一些额外的工作！

1.Cache

如果你之前是采用把Token存在cache里面这种方案，那么你只要删除cache里面的key就可以了。

2.用户关联

有人说，建一张表把uid和Token关联起来，这样一个用户只有一个有效的Token，或者存cache也行，建立uid和Token的一对一关系，这方案和1差不多。无论是存表还存cache，每次访问都必不可免的需要访问库或cache。

3.黑名单

在数据表或cache里面维护一个黑名单，也避免不了查库或者查cache，为了避免这个库内容过多，可以定期清理数据库，或者给cache设置一个有效期。比如说在上面说的例子里面，有效期应该设置为30天，30天之后就不用管了。

其实我比较喜欢第3种方案，第2种方案如果用户多了对库压力大，而第3种，除非用户经常修改密码或者退出登录，不然这个数据集不会很大。

如果不考虑安全，我们完全可以不考虑Token作废问题，那么我们就必须在防止XSS攻击上面做好工作，比如说使用https，cookies设置httpOnly。。。

【令牌的签发】
首先用户登录进来，我们先验证用户名/密码，验证通过后我们会生成两个 token(access_token、refresh_token 他们的唯一区别是一个过期时间短一般几个小时，一个过期时间长一般设置7天) 然后把一些必要的参数封装成 LoginRespVO 响应回客户端。token 主要包含 用户id、用户登录名、用户所拥有的角色、用户所拥有的权限、和签发单位标识。
然后由客户端浏览器存储起来

【令牌的重复使用】
令牌发放之后，借鉴Oauth2的设计：当access token过期而refresh token有效的时候，客户端使用后者重新获取新的access token，而老的access_token 用redis 标记起来并设置过期时间过期时间为该令牌剩余的过期时间（老的access_token在它剩余的过期时间里也要保持可使用）。每次使用refresh token刷新access token的时候，不光更新access token，refresh token 同样也更新。

【令牌的作废①】
在用户修改了密码，或登出时：清空 shiro/SpringSecurity等安全框架的一些缓存信息，然后把 access_token 加入黑名单、refresh_token 加入redis里维护的黑名单，并且设置过期时间过期时间为该令牌剩余的过期时间（发放的access_token/refresh_token 过期了，与之对应的黑名单也不用再维护了）。

【令牌的作废②】
在后台修改了角色/菜单权限时：把相关联用户都用redis标记为需要刷新令牌（更改jwt载荷里的用户权限、角色等信息）过期时间为access_token 生成的过期时间

【令牌的验证】
创建一个拦截器拦截用户请求

• 判断客户端是否携带accessToken
• 判断用户是否被锁定
• 判断用户是否被删除
• 判断用户是否是否主动退出（查黑名单）
• 判断access_token 是否通过校验(校验是否过期)
• 判断用户是否需要刷新（查需要刷新的名单）
  在判断用户是否需要刷新时，要注意：
  需要排除重新登录的用户，重新登录的用户，已经签发了新的token，新token里包含新的权限信息，所以不需要重新刷新了。就要比较这个accessToken和JWT_REFRESH_KEY+userId两者的剩余过期时间。如果JWT_REFRESH_KEY+userId大于accessToken说明这个 accessToken不是重新生成的。