做后端开发的几乎没人能绕过登录认证这道坎。之前带几个刚入行的朋友做项目十有八九都卡在这一块登录接口写好了却发现别人不登录也能直接调其它接口拿数据密码明文存数据库看着都心惊改个前端页面后端一重启token就失效。这些坑我基本都踩过一遍后来在做Tlias这个JavaWeb后台管理系统的时候才把整套登录认证链路彻底捋顺了。今天就把这套后端实战里最核心的登录认证部分拆开讲清楚从方案选型、JWT封装、MD5加盐、拦截器校验、ThreadLocal存取用户信息到问题排查一条龙讲完适合刚做完SSM或SpringBoot入门、想搞清楚“登录到底怎么落地”的朋友。1. 登录认证在Tlias项目里的定位1.1 先搞清楚后端项目里登录认证解决什么问题站在使用者的角度登录认证就是“输入用户名密码进系统干活”。但站在后端的角度登录认证真正要解决的是两个问题第一确认“你是谁”也就是身份认证。用户提交的用户名和密码要在后端和数据库里存的数据比对匹配上了才承认这个人的身份。第二确认“你配不配做这件事”也就是权限控制。比如Tlias项目里普通员工能看自己的考勤和薪资但只有管理员能修改员工信息、调整部门。后台管理系统不比门户网站很多接口涉及敏感数据不可能让任何人随便调。这两个问题在技术实现上是分开的认证靠登录接口完成权限控制靠拦截器加角色判断完成。但很多人写项目时只做了前者忘了后者接口裸奔这就是典型的只做了“登录页面”没做“登录认证”。Tlias这个项目里登录认证的落地方式是用户登录成功之后后端签发一个带签名和过期时间的令牌Token前端每次请求都带上这个令牌后端通过拦截器统一校验令牌是否有效、是否过期、属于哪个用户。整套方案属于无状态认证服务端不存Session扩展起来省心。1.2 为什么选JWT而不是Session不少初学者会问明明Servlet那一套Session机制也能做登录为什么非要用JWTSession机制的原理是用户登录后服务端把用户信息存在内存里生成一个JSESSIONID给浏览器存Cookie后续请求带上这个ID服务端就能找到对应的Session数据。听起来也不复杂但它有两个绕不开的痛点Session存在服务端内存中用户量上来后单机内存不够用做集群部署时用户的请求被负载均衡分发到另一台机器Session就找不到了还得专门做Session共享或粘滞会话。Session依赖Cookie传输而浏览器对Cookie的跨域支持很麻烦。现在前段后端分离前端页面可能跑在8080端口后端接口在9090端口跨域场景下Cookie处理起来非常头痛。JWT的思路完全反过来用户登录后服务端把用户ID、角色等信息加密签成一个字符串发给前端服务端自己不存任何状态。后续请求只要带这个字符串服务端验签通过就认账。用生活类比解释Session机制像去健身房办月卡前台电脑里记着你的名字和照片每次去都要核查档案JWT机制像拿了张带防伪钢印的VIP卡门口保安不查档案只验卡上的钢印和有效期。保安不占地方卡片丢了也不影响别的会员。对于Tlias这类中小型的后台管理系统JWT的“服务端无状态”这个特性太合适了部署简单、水平扩容无压力、前后端分离也顺畅。这也是我现在做JavaWeb项目默认选用JWT的原因。2. 登录认证方案的关键设计拆解2.1 登录认证核心链路整个登录认证流程可以拆成五步对应的代码模块也清清楚楚用户提交凭证前端把用户名和密码POST给后端的登录接口。后端验证密码Service层根据用户名查数据库拿到密码密文比对结果。签发Token密码匹配后后端把用户ID、用户名、角色等关键信息封装进JWT定好过期时间用密钥签名后返回给前端。前端存储Token前端把Token存在本地存储或内存中每次请求在Header里带token字段。后端校验Token拦截器拦截需要认证的请求解析Token验签名查过期时间。通过就把用户信息放进ThreadLocal供后续逻辑使用不通过直接返回401。这个链路中有一个容易被忽略的点登录接口本身不能被拦截器拦住。如果登录接口都被拦了用户还没拿到Token就要求先提供Token逻辑上就死循环了。所以拦截器一定要配置放行路径白名单里至少要包含登录接口、静态资源等。2.2 密码存储MD5加密和加盐处理聊完认证链路接着说密码存储。我见过不少初学者在数据库里直接明文存密码登录时直接查出来比对这么做在生产环境等于把用户密码挂在墙上。Tlias项目里用的是MD5加盐的方案。MD5是摘要算法把一个任意长度的字符串转成固定128位二进制通常以32位十六进制表示。它的特点是不可逆理论上你无法从密文反推出原文。但光用MD5是有问题的。现在网上有彩虹表常见密码的MD5值都被算好了你把123456的MD5存库里攻击者一看密文就知道原文是啥。所以我常提醒一句MD5必须加盐。加盐的意思是在用户原始密码后面拼一段随机字符串再对整个字符串做MD5。比如用户密码是abc123盐值是Tlias2024实际计算的是MD5(abc123Tlias2024)。盐值本身要存到数据库里同一个用户每次校验时用同一个盐不同用户的盐尽量不同。这样做的意义是就算两个用户密码相同密文也不一样就算攻击者拿到数据库没有盐值也难破解。但要注意MD5本身已经不够安全现在更稳妥的推荐是BCrypt这类自适应哈希算法。如果是从零开始做新项目建议直接用BCrypt。Tlias这个项目用MD5加盐是为了贴合教学场景、便于理解生产环境我一般会升级为BCrypt。2.3 JWT的结构和签名原理JWT全称JSON Web Token长这样eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwidXNlcm5hbWUiOiJhZG1pbiJ9.9nSY4WnO3qJxLqVlWnKQ8gX6YMeW0TkZbF6TUaFJhYc肉眼看着像一串乱码其实由三部分组成每部分用点号隔开Header头声明令牌类型和签名算法通常是{alg:HS256,typ:JWT}。这部分Base64编码不加密。Payload载荷存放实际传递的数据比如用户ID、用户名、过期时间。这里也是Base64编码不是加密所以敏感信息别往JWT里塞。Signature签名把前两段用Base64编码后的字符串拼接加上密钥再用Header里声明的算法HS256算出一个签名。签名的作用是防篡改只要前两段内容被改动签名对不上服务端验签就会失败。签名算法就是JWT安全性的根基。服务端有一个只有自己知道的密钥签发Token时用密钥算签名校验时再用同一个密钥算一遍签名比对是否一致。密钥就像前面健身卡例子里的防伪钢印只有官方有别人伪造不出来。常用的依赖是Java的jjwt库API设计得很简洁几行就能完成生成和解析。3. 后端实战从登录接口到拦截器3.1 环境准备和依赖引入我用的开发环境是Spring Boot 2.7版本JDK 1.8。先引入必要依赖。!-- JWT工具库 -- dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency !-- SpringBoot Web框架 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- Lombok简化实体类代码 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /dependency注意jjwt 0.9.1版本存在一个坑它依赖javax.xml.bind的JAXB模块在高版本JDK里默认被移除了运行时会报ClassNotFoundException: javax/xml/bind/DatatypeConverter。JDK 8没问题JDK 9以上就需要额外引入JAXB依赖我后面会给出解决办法。数据库表设计比较简单用户表核心字段是id、username、password、salt。我在项目里还加了name、avatar这些基础字段这里不再展开重点看登录相关的。3.2 创建统一返回结果类在真实项目中接口返回值不建议直接返回实体或Map最好是统一封装。Tlias项目里用了Result这个类结构很简单Data public class Result { private Integer code; // 1代表成功0代表失败 private String msg; // 提示信息 private Object data; // 返回的数据 public static Result success() { Result result new Result(); result.setCode(1); return result; } public static Result success(Object data) { Result result new Result(); result.setCode(1); result.setData(data); return result; } public static Result error(String msg) { Result result new Result(); result.setCode(0); result.setMsg(msg); return result; } }统一返回结果类的价值在于前端拿到响应后先判断code是不是1再决定下一步操作。这样整个项目的接口契约一致前端不用每个接口单独写一套判断逻辑。登录接口返回的是Token字符串就放在data字段里。3.3 登录接口的Service和Controller登录接口的Service层逻辑要处理三类情况用户名不存在直接提示“用户名或密码错误”。这里有个细节我之前会分别提示“用户名不存在”和“密码错误”后来被灌输了一个安全理念——不要暴露用户是否存在。攻击者可以用“用户名不存在”这个提示来遍历用户名所以统一返回“用户名或密码错误”更安全。密码校验失败同样返回“用户名或密码错误”。校验通过签发Token返回给前端。Service public class UserService { Autowired private UserMapper userMapper; Autowired private JwtUtils jwtUtils; public LoginInfo login(String username, String password) { // 1. 根据用户名查询用户 User user userMapper.findByUsername(username); if (user null) { throw new LoginException(用户名或密码错误); } // 2. 密码加盐后做MD5和数据库密文比对 String encryptedPassword Md5Util.getEncryptedPwd(password, user.getSalt()); if (!encryptedPassword.equals(user.getPassword())) { throw new LoginException(用户名或密码错误); } // 3. 签发JWT MapString, Object claims new HashMap(); claims.put(id, user.getId()); claims.put(username, user.getUsername()); claims.put(role, user.getRole()); String token jwtUtils.generateToken(claims); // 4. 返回Token和用户基本信息 LoginInfo loginInfo new LoginInfo(); loginInfo.setToken(token); loginInfo.setUsername(user.getUsername()); loginInfo.setRole(user.getRole()); return loginInfo; } }Controller层就薄薄一层RestController public class LoginController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody LoginRequest loginRequest) { LoginInfo loginInfo userService.login(loginRequest.getUsername(), loginRequest.getPassword()); return Result.success(loginInfo); } }注意两个细节登录请求体最好单独建一个LoginRequest类不要直接拿User实体接收。因为User实体往往含有多余字段比如salt一旦被人利用前端传进来的数据直接绑定到实体上可能造成安全隐患。密码比对不应该在前端做也不应该裸传明文密码到日志中。如果在开发调试阶段需要打日志严禁打印密码字段。3.4 JWT工具类的封装JWT工具类是整个认证模块的“地基”我把生成和解析封装在两个静态方法里Component public class JwtUtils { // 密钥生产环境必须放到配置中心或环境变量不能写死在代码里 private static final String SECRET_KEY tlias-secret-key-2024; // 过期时间2小时单位毫秒 private static final long EXPIRE_TIME 2 * 60 * 60 * 1000; // 生成Token public static String generateToken(MapString, Object claims) { return Jwts.builder() .setClaims(claims) // 自定义数据 .setExpiration(new Date(System.currentTimeMillis() EXPIRE_TIME)) // 过期时间 .signWith(SignatureAlgorithm.HS256, SECRET_KEY) // 签名算法和密钥 .compact(); } // 解析Token返回Claims public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); } }密钥设置有一些讲究。项目代码里写一个固定密钥是为了演示方便但生产环境绝对不行。密钥一旦泄露任何人都能自己签发有效Token整个认证体系就名存实亡了。正确做法是把密钥放到环境变量或配置中心部署时注入不同环境用不同密钥。过期时间的长短也是个权衡。太短用户频繁重新登录体验差太长Token被盗后风险窗口变大。Tlias项目里设2小时一般后台管理系统用2到4小时比较常见。有些系统还会做成双Token机制短期Token 长期Refresh TokenTlias属于教材项目单Token够用。3.5 MD5加盐工具类MD5加盐的实现思路是用户注册或初始化密码时生成一个随机盐值用MD5(密码 盐值)得到密文存入数据库。校验时取出盐值重新计算比对。盐值生成我推荐用UUID然后截取一段或者用SecureRandom生成随机字节数组转十六进制。UUID简单但严格来说熵值够用做项目没问题public class Md5Util { public static String getSalt() { String uuid UUID.randomUUID().toString(); return uuid.replace(-, ).substring(0, 8); } public static String getEncryptedPwd(String password, String salt) { // 拼接密码 盐值 String raw password salt; // 做MD5计算 return DigestUtils.md5DigestAsHex(raw.getBytes(StandardCharsets.UTF_8)); } public static void main(String[] args) { String salt getSalt(); String encrypted getEncryptedPwd(123456, salt); System.out.println(盐值: salt); System.out.println(密文: encrypted); } }这里有一个值得说清楚的点为什么是“密码 盐值”再加密而不是先加密密码再加盐原因很简单加盐的主要目的是让彩虹表失效。如果先做MD5再把盐拼到密文后面等于盐没有参与摘要计算彩虹表照样能命中密码部分。必须把盐混进原始密码里让摘要结果完全改变才达到加盐的效果。3.6 拦截器实现登录校验有了Token生成还不能算完成登录认证因为后端还没有任何机制确保“不带Token、带错Token的请求被拦在外面”。这个活儿交给拦截器。Spring MVC的拦截器是从Servlet Filter演化而来的在这里用HandlerInterceptor接口实现Component public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 1. 放行OPTIONS预检请求 if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } // 2. 从Header中获取Token String token request.getHeader(token); if (token null || token.isEmpty()) { // 未登录直接返回401并写入提示信息 response.setStatus(401); response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:0,\msg\:\未登录或登录已过期\}); return false; } // 3. 解析Token验签、查过期 try { Claims claims JwtUtils.parseToken(token); // 把当前用户ID保存到ThreadLocal ThreadLocalUtil.set(userId, claims.get(id)); ThreadLocalUtil.set(username, claims.get(username)); ThreadLocalUtil.set(role, claims.get(role)); return true; } catch (Exception e) { // Token被篡改或已过期 response.setStatus(401); response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:0,\msg\:\未登录或登录已过期\}); return false; } } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { // 防止内存泄漏请求结束后必须清理ThreadLocal ThreadLocalUtil.remove(); } }这段代码里有几个容易忽视的细节第一afterCompletion里必须调用ThreadLocalUtil.remove()。ThreadLocal在线程池场景下线程是复用的如果不清理下个请求复用同一个线程时能读到上一个请求的数据轻则数据串了重则导致越权访问。这是我强烈建议所有人养成的习惯。第二解析Token时我没有把用户信息直接返回给前端而是放进了ThreadLocal。好处是后续的Controller和Service代码里不用每个方法都接收一遍用户ID参数直接ThreadLocalUtil.get(userId)就能拿到当前登录用户代码会干净很多。第三跨域场景下前端自定义Header触发的是预检请求OPTIONS。预检请求不带业务Token如果拦截器不放行它前端就会报CORS错误但后端日志里又看不到具体异常。我最初排查这个问题时浪费了好些时间后来才知道要在拦截器里先放行OPTIONS。3.7 注册拦截器和白名单配置拦截器写好了还要注册进Spring MVC配置里指定哪些路径拦截、哪些路径放行。Configuration public class WebConfig implements WebMvcConfigurer { Autowired private LoginInterceptor loginInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns(/**) // 拦截所有路径 .excludePathPatterns( /login, // 登录接口放行 /register, // 注册接口放行 /captcha, // 图形验证码放行 /error // 错误页放行 ); } }白名单配置要精心设计。原则是任何在用户拿到Token之前就必须调用的接口都得放行。除了登录、注册、验证码如果有图片资源、静态页面、前端框架需要的接口也要逐项加到白名单里。我之前见过一个案例同事把/**全部拦截了结果前端页面静态资源全部404登录页都打不开。排查了半天才意识到静态资源的请求也被拦截器拦了。这就是白名单设计不细致导致的连锁问题。还有一个容易踩的坑路径匹配规则。excludePathPatterns里写/login只放行精确路径如果登录接口是/api/login要写/api/login否则拦截器照样拦。配置完之后一定用接口测试工具实际走一遍登录流程确认没有把自己拦在门外。3.8 ThreadLocal的封装和使用ThreadLocal在登录认证里扮演的角色是“当前请求的上下文容器”。每个请求进来拦截器把用户ID放进去请求结束清理掉。在同一个请求的处理过程中任意层都能拿到当前用户信息。我封装了一个简单的工具类public class ThreadLocalUtil { private static final ThreadLocalMapString, Object THREAD_LOCAL new ThreadLocal(); public static void set(String key, Object value) { MapString, Object map THREAD_LOCAL.get(); if (map null) { map new HashMap(); THREAD_LOCAL.set(map); } map.put(key, value); } public static Object get(String key) { MapString, Object map THREAD_LOCAL.get(); return map null ? null : map.get(key); } public static void remove() { THREAD_LOCAL.remove(); } }使用场景很典型修改员工信息时需要在Service里记录“这个操作是谁发起的”。没有ThreadLocal的话Controller方法从拦截器拿用户ID再传参给Service再传给Mapper每层方法签名都得多一个参数非常啰嗦。有了ThreadLocalService里直接Long userId (Long) ThreadLocalUtil.get(userId)就能拿到。但要记住ThreadLocal的适用范围它绑定的是当前线程。异步操作时新线程里拿不到原线程的ThreadLocal值这个场景就需要用阿里开源的TTLTransmittableThreadLocal来做线程间传递。Tlias项目目前没有异步链路用标准的ThreadLocal没问题。4. 实操验证和常见问题排查实录4.1 用接口测试工具跑通全流程登录认证代码写完之后别急着庆祝先得验证。我习惯用Postman或Apifox来做接口测试。第一步调用登录接口。请求方式是POST请求体是JSON{ username: admin, password: 123456 }正常情况下响应会包含成功状态码和数据{ code: 1, data: { token: eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwidXNlcm5hbWUiOiJhZG1pbiJ9.9nSY4WnO3qJxLqVlWnKQ8gX6YMeW0TkZbF6TUaFJhYc, username: admin, role: ADMIN } }第二步拿这个Token去请求一个需要认证的接口比如“查询部门列表”。请求时要在Header里加上token: eyJhbGciOiJIUzI1NiJ9...正常响应说明整个链路通了。第三步验证Token过期或无效的情况。可以手动把Token末尾改几个字符模拟篡改。此时应该返回401和“未登录或登录已过期”的提示。第四步验证不携带Token请求受限接口。同样应该返回401。这一套验证跑完登录认证才算真正落地。我在实践中把这一步做成“回归测试脚本”每次改动认证相关代码后都先过一遍防止改出低级问题。4.2 常见异常和排查清单这里梳理我在做Tlias登录认证时实际踩过、也帮别人排查过的高频问题每个都有对应的解决方向。问题一高版本JDK下启动报ClassNotFoundException: javax/xml/bind/DatatypeConverter原因就是jjwt 0.9.1依赖JAXB模块JDK 9以后不再内置。解决办法有两个升级到jjwt 0.11.5或更高版本API略微变化但不用处理JAXB依赖额外引入依赖dependency groupIdjavax.xml.bind/groupId artifactIdjaxb-api/artifactId version2.3.1/version /dependency个人建议升级版本毕竟JDK 8已经进入维护期很久了新项目直接JDK 17起步配套0.11.x的jjwt更省心。问题二登录后访问接口返回401但明明带了Token这种情况从三个方向查检查Header名是否正确。前端传的是token后端取的也是token大小写和拼写任何一处不一致都会取不到值。检查Token是否完整。有些前端框架会自动截断或转义长Token导致后端解析失败。检查密钥是否一致。JWT签发和解析用的密钥必须完全一致如果配置中心或环境变量在不同环境里覆盖了密钥就会出现“本地能过、测试环境过不了”的问题。问题三前端提示跨域后端却看不到拦截器日志八成是OPTIONS预检请求被拦截了。我前面提过在preHandle里放行OPTIONS或者在WebConfig里配置CORS。标准做法是两者都做并确保CORS处理优先级在拦截器之前或内部放行。问题四ThreadLocal数据串了症状是用户A登录后查询数据时偶尔能看到用户B的信息。绝大多数情况是afterCompletion里没清理ThreadLocal。线程池里的线程是复用的上一个请求的数据残留下个请求就串了。解决办法只有一个每个请求结束必须ThreadLocalUtil.remove()。问题五Token过期后前端不跳转登录页后端已经返回401了但前端没有统一处理用户停留在页面里点了半天没反应。这不是后端问题但作为后端开发者应该主动和前端约定好所有接口遇到401状态码时前端统一跳转登录页并清理本地缓存的Token。这个约定放在接口文档里省得后续扯皮。4.3 登录认证模块的扩展建议Tlias项目的登录认证是单角色、单Token的基础版本。实际工作中这个模块还能往这几个方向扩展角色权限控制现在的拦截器只校验“是否登录”不校验“是否有权限”。可以给每个接口配置要求的角色在拦截器里从ThreadLocal取出当前用户角色做比对不满足就返回403。登录失败次数限制防止暴力破解连续输错5次密码后锁定账号15分钟。实现方案是Redis计数器加过期时间。图形验证码登录接口增加验证码字段后端生成图片把答案存在Redis并设置5分钟过期。能挡掉一批脚本攻击。密码加密方案升级从MD5加盐换成BCrypt。BCrypt算法自带盐值、计算代价可调更符合当前安全要求。Spring Security的BCryptPasswordEncoder可以直接用即使不用Spring Security单独引入这个类也行。双Token机制短期TokenAccess Token有效期30分钟长期TokenRefresh Token有效期7天。Access Token过期后用Refresh Token换新用户无感知续期安全性也更高。这些扩展如果都做进去登录认证模块的完整度就比较接近实际生产项目了。Tlias作为教学项目把主线打通剩下的是一层层加功能的过程。我在实际操练这个项目时印象最深的不是JWT本身而是“完整链路”这四个字。登录认证不是一个Login方法的事它是从数据库密码设计、Token签发、传输、拦截校验、上下文传递到异常处理的整个闭环。每一步都有坑不加盐的MD5等于没加密拦截器漏放行自己都进不去ThreadLocal不清理数据会串预检请求不放行前端一片红。这些细节在视频教程里可能一两句话带过但落到自己代码里每一个都是真实的生产事故隐患。如果看完这篇你决定在自己项目里重写一遍登录认证我建议按这个顺序动手先封装Result和ThreadLocalUtil再做JwtUtils和Md5Util然后写登录Service和Controller最后写拦截器并注册。每写完一层停下来想想这层如果不写会发生什么问题。这套思考习惯比代码本身更值钱。
做后端开发的几乎没人能绕过登录认证这道坎。之前带几个刚入行的朋友做项目十有八九都卡在这一块登录接口写好了却发现别人不登录也能直接调其它接口拿数据密码明文存数据库看着都心惊改个前端页面后端一重启token就失效。这些坑我基本都踩过一遍后来在做Tlias这个JavaWeb后台管理系统的时候才把整套登录认证链路彻底捋顺了。今天就把这套后端实战里最核心的登录认证部分拆开讲清楚从方案选型、JWT封装、MD5加盐、拦截器校验、ThreadLocal存取用户信息到问题排查一条龙讲完适合刚做完SSM或SpringBoot入门、想搞清楚“登录到底怎么落地”的朋友。1. 登录认证在Tlias项目里的定位1.1 先搞清楚后端项目里登录认证解决什么问题站在使用者的角度登录认证就是“输入用户名密码进系统干活”。但站在后端的角度登录认证真正要解决的是两个问题第一确认“你是谁”也就是身份认证。用户提交的用户名和密码要在后端和数据库里存的数据比对匹配上了才承认这个人的身份。第二确认“你配不配做这件事”也就是权限控制。比如Tlias项目里普通员工能看自己的考勤和薪资但只有管理员能修改员工信息、调整部门。后台管理系统不比门户网站很多接口涉及敏感数据不可能让任何人随便调。这两个问题在技术实现上是分开的认证靠登录接口完成权限控制靠拦截器加角色判断完成。但很多人写项目时只做了前者忘了后者接口裸奔这就是典型的只做了“登录页面”没做“登录认证”。Tlias这个项目里登录认证的落地方式是用户登录成功之后后端签发一个带签名和过期时间的令牌Token前端每次请求都带上这个令牌后端通过拦截器统一校验令牌是否有效、是否过期、属于哪个用户。整套方案属于无状态认证服务端不存Session扩展起来省心。1.2 为什么选JWT而不是Session不少初学者会问明明Servlet那一套Session机制也能做登录为什么非要用JWTSession机制的原理是用户登录后服务端把用户信息存在内存里生成一个JSESSIONID给浏览器存Cookie后续请求带上这个ID服务端就能找到对应的Session数据。听起来也不复杂但它有两个绕不开的痛点Session存在服务端内存中用户量上来后单机内存不够用做集群部署时用户的请求被负载均衡分发到另一台机器Session就找不到了还得专门做Session共享或粘滞会话。Session依赖Cookie传输而浏览器对Cookie的跨域支持很麻烦。现在前段后端分离前端页面可能跑在8080端口后端接口在9090端口跨域场景下Cookie处理起来非常头痛。JWT的思路完全反过来用户登录后服务端把用户ID、角色等信息加密签成一个字符串发给前端服务端自己不存任何状态。后续请求只要带这个字符串服务端验签通过就认账。用生活类比解释Session机制像去健身房办月卡前台电脑里记着你的名字和照片每次去都要核查档案JWT机制像拿了张带防伪钢印的VIP卡门口保安不查档案只验卡上的钢印和有效期。保安不占地方卡片丢了也不影响别的会员。对于Tlias这类中小型的后台管理系统JWT的“服务端无状态”这个特性太合适了部署简单、水平扩容无压力、前后端分离也顺畅。这也是我现在做JavaWeb项目默认选用JWT的原因。2. 登录认证方案的关键设计拆解2.1 登录认证核心链路整个登录认证流程可以拆成五步对应的代码模块也清清楚楚用户提交凭证前端把用户名和密码POST给后端的登录接口。后端验证密码Service层根据用户名查数据库拿到密码密文比对结果。签发Token密码匹配后后端把用户ID、用户名、角色等关键信息封装进JWT定好过期时间用密钥签名后返回给前端。前端存储Token前端把Token存在本地存储或内存中每次请求在Header里带token字段。后端校验Token拦截器拦截需要认证的请求解析Token验签名查过期时间。通过就把用户信息放进ThreadLocal供后续逻辑使用不通过直接返回401。这个链路中有一个容易被忽略的点登录接口本身不能被拦截器拦住。如果登录接口都被拦了用户还没拿到Token就要求先提供Token逻辑上就死循环了。所以拦截器一定要配置放行路径白名单里至少要包含登录接口、静态资源等。2.2 密码存储MD5加密和加盐处理聊完认证链路接着说密码存储。我见过不少初学者在数据库里直接明文存密码登录时直接查出来比对这么做在生产环境等于把用户密码挂在墙上。Tlias项目里用的是MD5加盐的方案。MD5是摘要算法把一个任意长度的字符串转成固定128位二进制通常以32位十六进制表示。它的特点是不可逆理论上你无法从密文反推出原文。但光用MD5是有问题的。现在网上有彩虹表常见密码的MD5值都被算好了你把123456的MD5存库里攻击者一看密文就知道原文是啥。所以我常提醒一句MD5必须加盐。加盐的意思是在用户原始密码后面拼一段随机字符串再对整个字符串做MD5。比如用户密码是abc123盐值是Tlias2024实际计算的是MD5(abc123Tlias2024)。盐值本身要存到数据库里同一个用户每次校验时用同一个盐不同用户的盐尽量不同。这样做的意义是就算两个用户密码相同密文也不一样就算攻击者拿到数据库没有盐值也难破解。但要注意MD5本身已经不够安全现在更稳妥的推荐是BCrypt这类自适应哈希算法。如果是从零开始做新项目建议直接用BCrypt。Tlias这个项目用MD5加盐是为了贴合教学场景、便于理解生产环境我一般会升级为BCrypt。2.3 JWT的结构和签名原理JWT全称JSON Web Token长这样eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwidXNlcm5hbWUiOiJhZG1pbiJ9.9nSY4WnO3qJxLqVlWnKQ8gX6YMeW0TkZbF6TUaFJhYc肉眼看着像一串乱码其实由三部分组成每部分用点号隔开Header头声明令牌类型和签名算法通常是{alg:HS256,typ:JWT}。这部分Base64编码不加密。Payload载荷存放实际传递的数据比如用户ID、用户名、过期时间。这里也是Base64编码不是加密所以敏感信息别往JWT里塞。Signature签名把前两段用Base64编码后的字符串拼接加上密钥再用Header里声明的算法HS256算出一个签名。签名的作用是防篡改只要前两段内容被改动签名对不上服务端验签就会失败。签名算法就是JWT安全性的根基。服务端有一个只有自己知道的密钥签发Token时用密钥算签名校验时再用同一个密钥算一遍签名比对是否一致。密钥就像前面健身卡例子里的防伪钢印只有官方有别人伪造不出来。常用的依赖是Java的jjwt库API设计得很简洁几行就能完成生成和解析。3. 后端实战从登录接口到拦截器3.1 环境准备和依赖引入我用的开发环境是Spring Boot 2.7版本JDK 1.8。先引入必要依赖。!-- JWT工具库 -- dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency !-- SpringBoot Web框架 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- Lombok简化实体类代码 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /dependency注意jjwt 0.9.1版本存在一个坑它依赖javax.xml.bind的JAXB模块在高版本JDK里默认被移除了运行时会报ClassNotFoundException: javax/xml/bind/DatatypeConverter。JDK 8没问题JDK 9以上就需要额外引入JAXB依赖我后面会给出解决办法。数据库表设计比较简单用户表核心字段是id、username、password、salt。我在项目里还加了name、avatar这些基础字段这里不再展开重点看登录相关的。3.2 创建统一返回结果类在真实项目中接口返回值不建议直接返回实体或Map最好是统一封装。Tlias项目里用了Result这个类结构很简单Data public class Result { private Integer code; // 1代表成功0代表失败 private String msg; // 提示信息 private Object data; // 返回的数据 public static Result success() { Result result new Result(); result.setCode(1); return result; } public static Result success(Object data) { Result result new Result(); result.setCode(1); result.setData(data); return result; } public static Result error(String msg) { Result result new Result(); result.setCode(0); result.setMsg(msg); return result; } }统一返回结果类的价值在于前端拿到响应后先判断code是不是1再决定下一步操作。这样整个项目的接口契约一致前端不用每个接口单独写一套判断逻辑。登录接口返回的是Token字符串就放在data字段里。3.3 登录接口的Service和Controller登录接口的Service层逻辑要处理三类情况用户名不存在直接提示“用户名或密码错误”。这里有个细节我之前会分别提示“用户名不存在”和“密码错误”后来被灌输了一个安全理念——不要暴露用户是否存在。攻击者可以用“用户名不存在”这个提示来遍历用户名所以统一返回“用户名或密码错误”更安全。密码校验失败同样返回“用户名或密码错误”。校验通过签发Token返回给前端。Service public class UserService { Autowired private UserMapper userMapper; Autowired private JwtUtils jwtUtils; public LoginInfo login(String username, String password) { // 1. 根据用户名查询用户 User user userMapper.findByUsername(username); if (user null) { throw new LoginException(用户名或密码错误); } // 2. 密码加盐后做MD5和数据库密文比对 String encryptedPassword Md5Util.getEncryptedPwd(password, user.getSalt()); if (!encryptedPassword.equals(user.getPassword())) { throw new LoginException(用户名或密码错误); } // 3. 签发JWT MapString, Object claims new HashMap(); claims.put(id, user.getId()); claims.put(username, user.getUsername()); claims.put(role, user.getRole()); String token jwtUtils.generateToken(claims); // 4. 返回Token和用户基本信息 LoginInfo loginInfo new LoginInfo(); loginInfo.setToken(token); loginInfo.setUsername(user.getUsername()); loginInfo.setRole(user.getRole()); return loginInfo; } }Controller层就薄薄一层RestController public class LoginController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody LoginRequest loginRequest) { LoginInfo loginInfo userService.login(loginRequest.getUsername(), loginRequest.getPassword()); return Result.success(loginInfo); } }注意两个细节登录请求体最好单独建一个LoginRequest类不要直接拿User实体接收。因为User实体往往含有多余字段比如salt一旦被人利用前端传进来的数据直接绑定到实体上可能造成安全隐患。密码比对不应该在前端做也不应该裸传明文密码到日志中。如果在开发调试阶段需要打日志严禁打印密码字段。3.4 JWT工具类的封装JWT工具类是整个认证模块的“地基”我把生成和解析封装在两个静态方法里Component public class JwtUtils { // 密钥生产环境必须放到配置中心或环境变量不能写死在代码里 private static final String SECRET_KEY tlias-secret-key-2024; // 过期时间2小时单位毫秒 private static final long EXPIRE_TIME 2 * 60 * 60 * 1000; // 生成Token public static String generateToken(MapString, Object claims) { return Jwts.builder() .setClaims(claims) // 自定义数据 .setExpiration(new Date(System.currentTimeMillis() EXPIRE_TIME)) // 过期时间 .signWith(SignatureAlgorithm.HS256, SECRET_KEY) // 签名算法和密钥 .compact(); } // 解析Token返回Claims public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); } }密钥设置有一些讲究。项目代码里写一个固定密钥是为了演示方便但生产环境绝对不行。密钥一旦泄露任何人都能自己签发有效Token整个认证体系就名存实亡了。正确做法是把密钥放到环境变量或配置中心部署时注入不同环境用不同密钥。过期时间的长短也是个权衡。太短用户频繁重新登录体验差太长Token被盗后风险窗口变大。Tlias项目里设2小时一般后台管理系统用2到4小时比较常见。有些系统还会做成双Token机制短期Token 长期Refresh TokenTlias属于教材项目单Token够用。3.5 MD5加盐工具类MD5加盐的实现思路是用户注册或初始化密码时生成一个随机盐值用MD5(密码 盐值)得到密文存入数据库。校验时取出盐值重新计算比对。盐值生成我推荐用UUID然后截取一段或者用SecureRandom生成随机字节数组转十六进制。UUID简单但严格来说熵值够用做项目没问题public class Md5Util { public static String getSalt() { String uuid UUID.randomUUID().toString(); return uuid.replace(-, ).substring(0, 8); } public static String getEncryptedPwd(String password, String salt) { // 拼接密码 盐值 String raw password salt; // 做MD5计算 return DigestUtils.md5DigestAsHex(raw.getBytes(StandardCharsets.UTF_8)); } public static void main(String[] args) { String salt getSalt(); String encrypted getEncryptedPwd(123456, salt); System.out.println(盐值: salt); System.out.println(密文: encrypted); } }这里有一个值得说清楚的点为什么是“密码 盐值”再加密而不是先加密密码再加盐原因很简单加盐的主要目的是让彩虹表失效。如果先做MD5再把盐拼到密文后面等于盐没有参与摘要计算彩虹表照样能命中密码部分。必须把盐混进原始密码里让摘要结果完全改变才达到加盐的效果。3.6 拦截器实现登录校验有了Token生成还不能算完成登录认证因为后端还没有任何机制确保“不带Token、带错Token的请求被拦在外面”。这个活儿交给拦截器。Spring MVC的拦截器是从Servlet Filter演化而来的在这里用HandlerInterceptor接口实现Component public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 1. 放行OPTIONS预检请求 if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } // 2. 从Header中获取Token String token request.getHeader(token); if (token null || token.isEmpty()) { // 未登录直接返回401并写入提示信息 response.setStatus(401); response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:0,\msg\:\未登录或登录已过期\}); return false; } // 3. 解析Token验签、查过期 try { Claims claims JwtUtils.parseToken(token); // 把当前用户ID保存到ThreadLocal ThreadLocalUtil.set(userId, claims.get(id)); ThreadLocalUtil.set(username, claims.get(username)); ThreadLocalUtil.set(role, claims.get(role)); return true; } catch (Exception e) { // Token被篡改或已过期 response.setStatus(401); response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:0,\msg\:\未登录或登录已过期\}); return false; } } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { // 防止内存泄漏请求结束后必须清理ThreadLocal ThreadLocalUtil.remove(); } }这段代码里有几个容易忽视的细节第一afterCompletion里必须调用ThreadLocalUtil.remove()。ThreadLocal在线程池场景下线程是复用的如果不清理下个请求复用同一个线程时能读到上一个请求的数据轻则数据串了重则导致越权访问。这是我强烈建议所有人养成的习惯。第二解析Token时我没有把用户信息直接返回给前端而是放进了ThreadLocal。好处是后续的Controller和Service代码里不用每个方法都接收一遍用户ID参数直接ThreadLocalUtil.get(userId)就能拿到当前登录用户代码会干净很多。第三跨域场景下前端自定义Header触发的是预检请求OPTIONS。预检请求不带业务Token如果拦截器不放行它前端就会报CORS错误但后端日志里又看不到具体异常。我最初排查这个问题时浪费了好些时间后来才知道要在拦截器里先放行OPTIONS。3.7 注册拦截器和白名单配置拦截器写好了还要注册进Spring MVC配置里指定哪些路径拦截、哪些路径放行。Configuration public class WebConfig implements WebMvcConfigurer { Autowired private LoginInterceptor loginInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns(/**) // 拦截所有路径 .excludePathPatterns( /login, // 登录接口放行 /register, // 注册接口放行 /captcha, // 图形验证码放行 /error // 错误页放行 ); } }白名单配置要精心设计。原则是任何在用户拿到Token之前就必须调用的接口都得放行。除了登录、注册、验证码如果有图片资源、静态页面、前端框架需要的接口也要逐项加到白名单里。我之前见过一个案例同事把/**全部拦截了结果前端页面静态资源全部404登录页都打不开。排查了半天才意识到静态资源的请求也被拦截器拦了。这就是白名单设计不细致导致的连锁问题。还有一个容易踩的坑路径匹配规则。excludePathPatterns里写/login只放行精确路径如果登录接口是/api/login要写/api/login否则拦截器照样拦。配置完之后一定用接口测试工具实际走一遍登录流程确认没有把自己拦在门外。3.8 ThreadLocal的封装和使用ThreadLocal在登录认证里扮演的角色是“当前请求的上下文容器”。每个请求进来拦截器把用户ID放进去请求结束清理掉。在同一个请求的处理过程中任意层都能拿到当前用户信息。我封装了一个简单的工具类public class ThreadLocalUtil { private static final ThreadLocalMapString, Object THREAD_LOCAL new ThreadLocal(); public static void set(String key, Object value) { MapString, Object map THREAD_LOCAL.get(); if (map null) { map new HashMap(); THREAD_LOCAL.set(map); } map.put(key, value); } public static Object get(String key) { MapString, Object map THREAD_LOCAL.get(); return map null ? null : map.get(key); } public static void remove() { THREAD_LOCAL.remove(); } }使用场景很典型修改员工信息时需要在Service里记录“这个操作是谁发起的”。没有ThreadLocal的话Controller方法从拦截器拿用户ID再传参给Service再传给Mapper每层方法签名都得多一个参数非常啰嗦。有了ThreadLocalService里直接Long userId (Long) ThreadLocalUtil.get(userId)就能拿到。但要记住ThreadLocal的适用范围它绑定的是当前线程。异步操作时新线程里拿不到原线程的ThreadLocal值这个场景就需要用阿里开源的TTLTransmittableThreadLocal来做线程间传递。Tlias项目目前没有异步链路用标准的ThreadLocal没问题。4. 实操验证和常见问题排查实录4.1 用接口测试工具跑通全流程登录认证代码写完之后别急着庆祝先得验证。我习惯用Postman或Apifox来做接口测试。第一步调用登录接口。请求方式是POST请求体是JSON{ username: admin, password: 123456 }正常情况下响应会包含成功状态码和数据{ code: 1, data: { token: eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwidXNlcm5hbWUiOiJhZG1pbiJ9.9nSY4WnO3qJxLqVlWnKQ8gX6YMeW0TkZbF6TUaFJhYc, username: admin, role: ADMIN } }第二步拿这个Token去请求一个需要认证的接口比如“查询部门列表”。请求时要在Header里加上token: eyJhbGciOiJIUzI1NiJ9...正常响应说明整个链路通了。第三步验证Token过期或无效的情况。可以手动把Token末尾改几个字符模拟篡改。此时应该返回401和“未登录或登录已过期”的提示。第四步验证不携带Token请求受限接口。同样应该返回401。这一套验证跑完登录认证才算真正落地。我在实践中把这一步做成“回归测试脚本”每次改动认证相关代码后都先过一遍防止改出低级问题。4.2 常见异常和排查清单这里梳理我在做Tlias登录认证时实际踩过、也帮别人排查过的高频问题每个都有对应的解决方向。问题一高版本JDK下启动报ClassNotFoundException: javax/xml/bind/DatatypeConverter原因就是jjwt 0.9.1依赖JAXB模块JDK 9以后不再内置。解决办法有两个升级到jjwt 0.11.5或更高版本API略微变化但不用处理JAXB依赖额外引入依赖dependency groupIdjavax.xml.bind/groupId artifactIdjaxb-api/artifactId version2.3.1/version /dependency个人建议升级版本毕竟JDK 8已经进入维护期很久了新项目直接JDK 17起步配套0.11.x的jjwt更省心。问题二登录后访问接口返回401但明明带了Token这种情况从三个方向查检查Header名是否正确。前端传的是token后端取的也是token大小写和拼写任何一处不一致都会取不到值。检查Token是否完整。有些前端框架会自动截断或转义长Token导致后端解析失败。检查密钥是否一致。JWT签发和解析用的密钥必须完全一致如果配置中心或环境变量在不同环境里覆盖了密钥就会出现“本地能过、测试环境过不了”的问题。问题三前端提示跨域后端却看不到拦截器日志八成是OPTIONS预检请求被拦截了。我前面提过在preHandle里放行OPTIONS或者在WebConfig里配置CORS。标准做法是两者都做并确保CORS处理优先级在拦截器之前或内部放行。问题四ThreadLocal数据串了症状是用户A登录后查询数据时偶尔能看到用户B的信息。绝大多数情况是afterCompletion里没清理ThreadLocal。线程池里的线程是复用的上一个请求的数据残留下个请求就串了。解决办法只有一个每个请求结束必须ThreadLocalUtil.remove()。问题五Token过期后前端不跳转登录页后端已经返回401了但前端没有统一处理用户停留在页面里点了半天没反应。这不是后端问题但作为后端开发者应该主动和前端约定好所有接口遇到401状态码时前端统一跳转登录页并清理本地缓存的Token。这个约定放在接口文档里省得后续扯皮。4.3 登录认证模块的扩展建议Tlias项目的登录认证是单角色、单Token的基础版本。实际工作中这个模块还能往这几个方向扩展角色权限控制现在的拦截器只校验“是否登录”不校验“是否有权限”。可以给每个接口配置要求的角色在拦截器里从ThreadLocal取出当前用户角色做比对不满足就返回403。登录失败次数限制防止暴力破解连续输错5次密码后锁定账号15分钟。实现方案是Redis计数器加过期时间。图形验证码登录接口增加验证码字段后端生成图片把答案存在Redis并设置5分钟过期。能挡掉一批脚本攻击。密码加密方案升级从MD5加盐换成BCrypt。BCrypt算法自带盐值、计算代价可调更符合当前安全要求。Spring Security的BCryptPasswordEncoder可以直接用即使不用Spring Security单独引入这个类也行。双Token机制短期TokenAccess Token有效期30分钟长期TokenRefresh Token有效期7天。Access Token过期后用Refresh Token换新用户无感知续期安全性也更高。这些扩展如果都做进去登录认证模块的完整度就比较接近实际生产项目了。Tlias作为教学项目把主线打通剩下的是一层层加功能的过程。我在实际操练这个项目时印象最深的不是JWT本身而是“完整链路”这四个字。登录认证不是一个Login方法的事它是从数据库密码设计、Token签发、传输、拦截校验、上下文传递到异常处理的整个闭环。每一步都有坑不加盐的MD5等于没加密拦截器漏放行自己都进不去ThreadLocal不清理数据会串预检请求不放行前端一片红。这些细节在视频教程里可能一两句话带过但落到自己代码里每一个都是真实的生产事故隐患。如果看完这篇你决定在自己项目里重写一遍登录认证我建议按这个顺序动手先封装Result和ThreadLocalUtil再做JwtUtils和Md5Util然后写登录Service和Controller最后写拦截器并注册。每写完一层停下来想想这层如果不写会发生什么问题。这套思考习惯比代码本身更值钱。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
