前言
有一个看我SpringCloud alibaba系列文章的粉丝私下问我:如何处理jwt失效的问题?修改密码或退出登录后需要将之前的jwt token失效掉,不允许使用旧token登录系统。
我说:很简单呀,咱们直接 无为而治,用户退出或修改密码的时候前端直接删除这个token不就完了吗?后端啥都不用管,啥也不用做。
他说:别闹,你的每篇文章我都给你一键三连。
我当时就被感动了,既然是这样的好读者,我果断答应专门给他写篇文章来分享一下我这个不太成熟的做法,改造一下这个SpringCloud alibaba项目。
在正式开始之前,我们先来回顾一下oauth2中token的相关知识。
知识回顾
众所周知,在 OAuth2 体系中认证通过后返回的令牌信息分为两大类:不透明令牌(opaque tokens) 和 透明令牌(not opaque tokens)。
不透明令牌 是一种无可读性的令牌,一般来说就是一段普通的 UUID 字符串。使用不透明令牌时资源服务不知道这个令牌是什么,代表谁,需要调用认证服务器校验、获取用户信息。使用不透明令牌采用的是 中心化 的架构。
透明令牌 一般指的是我们常说的JWT Token,用户信息保存在 JWT 字符串中,资源服务器自己可以解析令牌不再需要去认证服务器校验令牌。使用JWT是属于 无状态、去中心化 的架构。
一旦我们选择了使用JWT,就需要明确一点:在不借助外力的情况下,让JWT失效的唯一途径就是等token自己过期,无法做到主动让JWT失效。非要让JWT有主动失效的功能只能借助外力,即在服务端存储JWT的状态,在请求时添加判断逻辑,这个与JWT的无状态化、去中心化特性是矛盾的。但是,既然选择了JWT这条路,那就只能接受这个现实。
解决思路
上面说了,要实现JWT的主动失效需要借助外力,在服务端存储JWT的状态,一般使用Redis等高速缓存。而存储JWT状态又分为两种方案:
-
白名单机制
认证通过时,把JWT存到Redis中。注销时,从缓存移除JWT。请求资源添加判断JWT在缓存中是否存在,不存在拒绝访问。这种方式和cookie/session机制中的会话失效删除session基本一致。
-
黑名单机制
注销登录时,缓存JWT至Redis,且缓存有效时间设置为JWT的有效期,请求资源时判断是否存在缓存的黑名单中,存在则拒绝访问。
白名单和黑名单的实现逻辑差不多,黑名单不需每次登录都将JWT缓存,仅仅在某些特殊场景下需要缓存JWT,给服务器带来的压力要远远小于白名单的方式。
我更倾向于使用黑名单机制,