Redis集群里搞JWT认证，安全又高效的那些事儿分享

（一）

这事儿得从我们团队最近一次系统升级说起,原先的用户认证，就是最普通的那种，用户名密码登录，服务器生成个Session存起来，用户再多点，系统就有点顶不住了，尤其是搞活动的时候，登录那块儿老是卡顿，我们就琢磨着，得换个更利索的法子，这时候，JWT（JSON Web Token）和Redis集群就进入了我们的视线。

简单说,JWT就像是一张“数字身份证”，用户第一次登录成功，服务器就给他签发这张身份证，里面用一种密码学方法（比如HMAC SHA256）签了个名，保证没人能随便篡改，这张身份证里就写着你是谁、有啥权限、啥时候过期，以后用户再来访问，就不用每次都查数据库验密码了，只需要把这张身份证（JWT Token）带过来，服务器验一下签名和有效期，没问题就放行，这样一来，服务器就轻松多了，因为它是“无状态”的，自己不用记谁登录了，压力自然就小了。

（二）

但光用JWT,有个挺头疼的问题，注销”和“踢人”不好办，因为JWT一旦发出去，在它自然过期之前，理论上都是有效的，你不能像废掉一张纸质票据那样，直接让中央服务器宣布它作废，比如用户主动退出登录，或者管理员发现异常把某个用户踢下线，这时候怎么让那个已经发出去的JWT立刻失效呢？

这时候就得请Redis集群出马了,我们的办法是，把JWT的ID（就是那个jti claim）和它的过期时间，在登录成功的时候，一起存到Redis集群里，我们把JWT本身的过期时间设得短一点，比如15分钟，我们再搞一个机制，叫“刷新令牌”（Refresh Token），这个刷新令牌是一个随机的、比较长的字符串，它的过期时间可以设得长一些，比如7天，这个刷新令牌也会被存到Redis集群里，并且跟对应用户的JWT ID关联起来。

（三）

具体流程是这样的：

1. 登录： 用户用密码登录成功，服务器生成一个短期有效的JWT和一个长期有效的刷新令牌，把JWT的ID和过期时间存进Redis，同时也把刷新令牌和它的信息存进去。
2. 访问API： 用户拿着JWT来访问，服务器除了常规验证JWT签名和过期时间，还会多一步：去Redis集群里查一下这个JWT的ID是不是还存在，如果Redis里已经没了（比如被手动删了），就算JWT本身没到期，也认为是无效的，拒绝访问，这就解决了“即时注销”的问题。
3. 刷新令牌： 当JWT快过期时（比如还剩5分钟），客户端不是让用户重新登录，而是用那个刷新令牌去换一个新的JWT，服务器收到刷新请求，会做几件事：
   • 检查刷新令牌本身有没有过期。
   • 去Redis里核对这个刷新令牌是否存在、是否有效。
   • 如果都OK,就签发一个全新的JWT，同时可以让旧的刷新令牌失效（从Redis删掉），生成一个新的刷新令牌给它，也可以选择让刷新令牌在有效期内一直可用，看安全策略怎么定。

这么一来,安全性和灵活性就都有了，想踢掉一个用户？简单，直接去Redis里把他对应的JWT ID和刷新令牌删掉，他手里的所有令牌立刻就废了，因为每次关键验证都要跑Redis里查一下，所以Redis的速度至关重要。

（四）

为啥非得是Redis集群,而不是单机的Redis呢？主要还是为了“高效”和“可靠”，用户量一大，认证请求海了去了，单机Redis容易成瓶颈，万一它挂了，整个认证系统就瘫了，用Redis集群，可以把数据分片存到多台机器上，性能能线性增长，扛得住高并发，而且集群有故障转移的能力，一台机器坏了，别的机器能顶上来，服务不会中断。

我们实践中还注意了几个小细节：

• Redis key的命名： 比如用 jwt_blacklist:<jti> 来存黑掉的JWT，用 refresh_token:<token> 来存储刷新令牌，清晰明了。
• 过期时间管理： 设置Redis里key的过期时间时，最好比JWT本身的过期时间稍微长一点，比如JWT有效期15分钟，Redis里设20分钟过期，这是为了避免一种极端情况：JWT还没到期，但Redis里的记录因为网络延迟之类的原因先过期了，导致正常的Token被误判为无效。
• 监控： 一定要盯着Redis集群的性能指标，比如连接数、内存使用量、操作延迟，认证可是系统的入口，这儿要是慢了，整个系统体验都差。

（五）

把JWT的无状态、轻量级好处，和Redis集群的高性能、高可用特性捏在一起，确实能搭出一个既安全又利索的认证方案，它解决了纯JWT无法及时注销的短板，又借助Redis集群保证了在高并发场景下的处理能力，没有十全十美的方案，这玩意儿对Redis的依赖性很强，运维Redis集群需要一定的技术储备，对于我们这种用户量大、对响应速度要求高的场景，这套组合拳打下来，效果是立竿见影的，用户登录快了，我们管理起来也方便了，算是双赢。