RuoYi若依源码分析2 - JWT认证与TokenService深度解析

1. 从登录到鉴权：JWT在RuoYi中扮演的角色

大家好，我是老张，一个在Java后端摸爬滚打了十多年的老码农。上次我们聊了RuoYi框架中Spring Security的整体配置，很多朋友反馈说对那个神秘的JwtAuthenticationTokenFilter和TokenService特别感兴趣，想知道一个简单的登录请求，背后到底是怎么从一串字符串变成系统认识的“自己人”的。今天，我们就来深挖一下这块内容，这绝对是RuoYi安全体系里最核心、也最值得玩味的部分。

想象一下这个场景：你打开若依的管理后台，输入用户名密码点击登录。一瞬间，页面跳转了，侧边栏菜单、用户信息都加载出来了。后续你点开任何一个页面，查询任何一张报表，系统都认得你，知道你是谁，能干什么。这个过程中，你的浏览器和服务器之间，并没有像传统系统那样，反复地携带一个叫“Session ID”的通行证。那靠的是什么？就是今天的主角——JWT，以及围绕它构建的一整套TokenService服务。

JWT，全称JSON Web Token，你可以把它理解成一张“数字身份证”。这张身份证很特别，它不是存在服务器的保险柜里（Session），而是直接发给你（客户端）自己保管。每次你要访问系统（发起请求），就把这张身份证掏出来给门卫（服务器）看。门卫不需要去翻厚厚的档案册（查Session存储），他只需要用特定的“验钞机”（密钥和验证逻辑）照一下这张身份证，就能判断真伪，读出里面的信息（用户ID、权限等），然后放行。这种“无状态”的设计，正是现代分布式架构的宠儿，因为它让服务器的扩展变得无比轻松，不用再为Session共享而头疼。

在RuoYi里，这套机制的运转中枢，就是我们今天要拆解的TokenService。它绝不仅仅是一个生成和解析字符串的工具类，而是一个集身份凭证管理、会话生命周期控制、安全审计于一体的核心服务。接下来，我就带大家走进源码，看看这张“数字身份证”是怎么从无到有被制作出来，又是怎么在每一次请求中被反复检验和刷新的。我们会从最外层的过滤器切入，一步步深入到令牌生成、验证、刷新的每一个细节，并且我会结合自己在实际项目中遇到的“坑”，告诉你哪些配置参数是关键，如何根据你的业务进行调整。相信我，看完之后，你不仅能彻底搞懂RuoYi的认证流程，自己动手实现一套类似的机制也完全不在话下。

2. 令牌的诞生与分发：深入TokenService.createToken方法

当我们成功登录，用户名密码验证通过后，系统就需要为我们制作那张唯一的“数字身份证”了。这个光荣的任务，就落在了TokenService的createToken方法上。别小看这个方法，它里面藏着不少设计上的巧思和安全上的考量。

首先，我们得明确输入是什么。createToken方法接收一个LoginUser对象作为参数。这个LoginUser可不简单，它继承了Spring Security的User类，里面除了用户名、密码这些基本信息，还扩展了RuoYi特有的用户ID、部门ID、角色权限列表、以及登录时间、登录IP等丰富的上下文信息。也就是说，在调用这个方法时，用户已经是一个被系统完全识别和验证的实体了。

方法的第一步，是生成一个唯一的令牌键（token）。你可能会想，直接用JWT本身不就行了吗？为什么还要多此一举？这里就涉及到一个重要的设计：令牌与用户信息的解耦。RuoYi生成的这个token，实际上是一个UUID字符串，它本身不携带任何信息，只是一个“钥匙编号”。真正的用户信息（即那个LoginUser对象）被以这个token为键，存放在了Redis缓存中。而最终返回给前端的JWT字符串，则是用这个token作为核心载荷（subject）制作出来的。这样做的好处非常明显：安全性和可控性。即使JWT被截获，攻击者拿到的也只是一个无法直接反解出用户信息的UUID；同时，服务端可以随时通过让Redis中的缓存失效，来立即吊销某个令牌，实现了类似Session注销的效果，弥补了JWT本身无法在有效期内主动失效的短板。

接下来，我们看看JWT本身是怎么被构造出来的。RuoYi使用了io.jsonwebtoken这个流行的库。createToken私有方法负责具体的组装工作：