jwt token 过期刷新_JWT Token 刷新和作废

之前一篇文章简单介绍了下JWT的用法,涉及到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。

这种方案简单粗暴，存在性能问题，还有安全问题，以前的那么多Token咋办？

2.快过期的时候更新Token

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

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

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

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

4.使用refreshToken

借鉴 oauth2 的设计，返回给客户端一个 refreshToken，允许客户端主动刷新JWT。一般而言，jwt 的过期时间可以设置为数小时，而 refreshToken 的过期时间设置为数天。 我对oauth2不太熟悉，不过很明显这个方案更加复杂了，而且为什么不拿旧的Token去刷新JWT呢？

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就可以了。不过如果你真的是采用这种方案，还不如直接用session，这时候的Token和sessionid没区别。

2.用户关联

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

3.黑名单

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

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

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

是否需要使用JWT Token？

看完之后大家是否发现原来JWT Token并没有那么好用，这也是很多人说的不要采用JWT的原因了: 讲真，别再使用JWT了！、请停止使用 JWT 认证 。。。

仔细看完这些文章其实大家会发现JWT尤其适合那些一次性验证的应用，比如说有些网站的文件下载为了防止盗链，会在url后面追加一些字符串，这些字符串其实就是Token，它里面可能包含了用户信息和过期时间，你发送给别人下载或者想盗链就非常麻烦了。

至于用不用我觉得还是看需求，你觉得呢？