JWT引入后的问题及优化方案：无感续签与token失效管理？-灵析社区

引入JWT所带来的问题： 1. token到期后需要无感续签； 目前主流方案是采用双token机制，accessToken访问令牌、refreshToken刷新令牌； 2. 已签发的token服务端无法主动将其失效； 场景1：用户退出登录 （需要将该次登录签发的accessToken和refreshToken同时失效）； 场景2：用户修改密码、服务端修改了某个用户具有的权限或者角色、用户的帐户被封禁/删除。。。。； （需要将该用户签发的所有token都失效）； 目前网上大多数方案是使用黑名单机制，直接将accessToken存到黑名单并设置过期时间； 但是这样还是有其他问题并未解决。 > 首先，签发出去的accessToken和refreshToken之间没有关联关系，用户退出登录时无法同时将refreshToken也失效。 > 其次，用户密码泄露被别人恶意登录，用户紧急修改密码。由于不知道当前签发了哪些token，无法使其全部都失效 > > （有一个方案是每个用户单独有自己的secretKey，改密码后直接将secretKey变更，但是这种方案验签时每次都要先从数据库查询出secretKey，成本太高）。 > 再次，由于JWT生成的token一般都比较长，直接将其存到缓存对内存占用也比较大。 由此对第2点做如下优化： 这里依然使用黑名单机制，不过额外再引入两个字段（token序列号，token批次号），token序列号作为关联此次登录的accessToken和refreshToken，token批次号作为关联密码变更前签发的所有token。 1. 在系统增加一个全局自增变量（由Redis自增incr）作为token序列号，暂时命名为`tokenSeqNum`。 2. 在数据库user表中增加一个字段`tokenBatchNum`作为token批次号。 3. 用户登录成功时，tokenSeqNum全局incr，从user表中取到当前用户的tokenBatchNum； 将username、tokenSeqNum、tokenBatchNum添加到JWT的payload中。 4. 用户退出登录时，从accessToken中解析出username、tokenSeqNum，拼接username_tokenSeqNum做为缓存key存入Redis黑名单，并设置过期时间。 5. 用户修改密码时，从user表中取到了用户当前的tokenBatchNum，更新用户表时同时更新tokenBatchNum = tokenBatchNum + 1，拼接username_tokenBatchNum做为缓存key存入Redis黑名单，并设置过期时间。 6. 用户请求受保护资源、或请求刷新token时，进行黑名单校验； 首先从token中解析出username、tokenSeqNum、tokenBatchNum； 如果用户操作了退出登录，则username_tokenSeqNum存在黑名单中，判断为签名已失效； 如果用户修改了密码，则username_tokenBatchNum存在黑名单中，判断为签名已失效； 如此。既可以解决关联失效问题，又能节省内存空间。 关于以上想法，欢迎大家一起探讨是否可行。