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,它里面可能包含了用户信息和过期时间,你发送给别人下载或者想盗链就非常麻烦了。

至于用不用我觉得还是看需求,你觉得呢?