1. 为什么“RedisCookie”成了SSO落地最稳的组合拳最近帮某高校实验室重构一套跨平台教学管理后台核心诉求就一条学生用学号密码在教务系统登录后点开实验预约系统、成绩查询模块、在线考试平台全程不用再输一遍账号密码。这听起来就是个标准的单点登录SSO场景。但真正动手时才发现市面上那些动辄几十页文档的OAuth2.0方案、SAML协议堆叠对一个只有3人维护、服务器资源有限的内部系统来说不是杀鸡用牛刀是直接把鸡和刀一起炖了。我们最终选了最朴素的路径Java后端 Redis缓存 浏览器Cookie。没有引入Spring Security OAuth2的全套依赖没碰JWT的签名验签链路甚至没动Nginx的反向代理配置。整个流程跑通后我盯着控制台里那行Login success, SSO token saved to Redis发了会儿呆——原来SSO的底层逻辑真可以这么轻。这个组合之所以“稳”关键在于它把问题拆解得足够干净Redis不是当数据库用而是当一个带过期时间的、全集群共享的“临时票据抽屉”。你生成一个随机字符串作为token把它和用户ID、基础权限信息一起塞进去设好15分钟过期就完事了。它不存密码不存敏感字段只存“此刻这个人是谁、能干啥”的快照。Cookie也不是随便写个Set-Cookie: tokenabc123就完事。它必须带HttpOnly防JS读取、Secure仅HTTPS传输、SameSiteStrict防CSRF这三个属性缺一不可。我试过漏掉HttpOnly前端同学随手写了个document.cookie就拿到了token当场被我拦住——这不是SSO这是给攻击者递钥匙。Java后端的角色是那个严格守门的“票据核验员”。每次请求进来它不查数据库只去Redis里找这个token对应的用户信息找不到401找到了但权限不够403一切正常放行并把用户上下文注入到当前线程里比如用ThreadLocal存CurrentUserContext。很多人一提SSO就默认要上中心化认证服务其实大可不必。当你面对的是几个同域下的子系统比如app.example.com、exam.example.com、score.example.com且它们都由同一套Java后端支撑时“RedisCookie”就是那个既不增加运维复杂度、又不会在高并发下崩盘的黄金解法。它不炫技但每一步都踩在真实业务的痛点上快、稳、易维护。提示这个方案的前提是所有子系统共享同一个根域名如.example.com这样才能让Cookie在多个子域间自动携带。如果系统分散在完全不同的域名下比如a.com和b.net这套方案就失效了得另寻他路。2. Token生命周期管理从生成、校验到自动续期的闭环设计SSO最怕的不是登录失败而是用户正填着表单突然弹出“登录已过期请重新登录”的提示。这种体验断层比一开始就不让登录还伤用户信任。所以Token的生命周期管理必须像设计交通信号灯一样精密——既要防超时又要避免频繁重登。2.1 Token生成随机性与唯一性的双重保障我们没用UUID也没用时间戳拼接。而是采用SecureRandom生成32字节的随机字节数组再用Base64Url编码注意是Url安全版本把和/换成-和_去掉末尾public static String generateToken() { SecureRandom random new SecureRandom(); byte[] bytes new byte[32]; random.nextBytes(bytes); return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes); }为什么不用UUID因为UUIDv4虽然随机但它的熵值信息量理论上限是122位而32字节的随机数是256位暴力碰撞难度呈指数级增长。更重要的是UUID有固定格式8-4-4-4-12攻击者一旦摸清规律可能针对性爆破。而纯随机字节Base64Url输出是32个字符的无规律字符串连长度都统一更难被模式识别。生成后Token不是直接扔进Redis。我们存的是一个结构化对象{ userId: U2023001, username: 张三, roles: [student, lab_member], loginTime: 1717023456000, lastAccessTime: 1717023456000, ipAddress: 192.168.1.105 }这个JSON串用Jackson序列化后存入RedisKey就是Token本身过期时间设为15分钟。注意lastAccessTime字段至关重要它是我们实现“滑动过期”的锚点。2.2 滑动过期机制用户不动Token也不死传统TTLTime-To-Live是“生成即倒计时”不管用户是否还在操作15分钟后一律作废。这显然不合理。我们的做法是每次成功校验Token后重置Redis中该Key的过期时间并更新lastAccessTime字段。校验逻辑伪代码如下public SsoUser validateToken(String token) { String json redisTemplate.opsForValue().get(token); if (json null) { return null; // Token不存在或已过期 } SsoUser user objectMapper.readValue(json, SsoUser.class); // 检查是否超过最大空闲时间比如30分钟 long idleTime System.currentTimeMillis() - user.getLastAccessTime(); if (idleTime 30 * 60 * 1000) { redisTemplate.delete(token); // 主动清理 return null; } // 更新最后访问时间并重置Redis过期时间 user.setLastAccessTime(System.currentTimeMillis()); redisTemplate.opsForValue().set(token, objectMapper.writeValueAsString(user), 15, TimeUnit.MINUTES); return user; }这里有两个关键阈值Redis TTL 15分钟这是物理层面的硬性过期防止Token无限续命。逻辑空闲超时 30分钟这是业务层面的软性限制只要用户30分钟内有过任何操作Token就一直有效。这个双阈值设计让用户体验丝滑学生连续刷题2小时Token自动续了8次他根本感觉不到后台在默默工作而如果他打开页面后去吃饭、回来看到登录页也只会觉得“哦太久没动安全起见重新登一下”而不是“刚填一半的表单没了”。2.3 Token主动注销不只是删Redis Key那么简单用户点击“退出登录”不能只删Redis里的Key就完事。我们遇到过真实案例A同学在图书馆电脑登了账号忘了点退出直接关机走人B同学接着用同一台电脑发现还能直接进系统——因为Cookie没清除Redis Key又被A同学的操作续了命。解决方案是引入“Token黑名单”。退出时除了删除Redis Key还要把该Token加进一个短期存在的黑名单// 退出逻辑 public void logout(String token) { // 1. 删除主Token redisTemplate.delete(token); // 2. 加入黑名单有效期5分钟覆盖可能的网络延迟 redisTemplate.opsForValue().set(blacklist: token, 1, 5, TimeUnit.MINUTES); } // 校验逻辑新增检查 public SsoUser validateToken(String token) { // ... 前面的校验步骤 // 新增检查是否在黑名单 if (redisTemplate.hasKey(blacklist: token)) { return null; } // ... 后续更新逻辑 }黑名单的存在时间5分钟很讲究太短如1秒网络抖动可能导致刚登出就又能登太长如30分钟用户真正想登出时反而要等很久。5分钟是经过压测后平衡安全与体验的结果——它足够覆盖一次HTTP请求的完整往返又不会让用户等得焦虑。注意黑名单本身也用Redis存储但用的是String类型而非Hash因为hasKey()操作在Redis里是O(1)复杂度而HGET在大数据量下可能退化。性能和安全永远要算这笔账。3. Cookie的安全防线HttpOnly、Secure与SameSite的实战取舍很多团队把SSO做崩不是败在Redis配置而是栽在Cookie的一行Set-Cookie头里。我见过最离谱的案例开发同学为了“方便调试”把HttpOnlyfalse结果前端一个console.log(document.cookie)就把所有用户的token打印在了控制台里——这已经不是漏洞是裸奔。3.1 HttpOnly第一道不可逾越的墙HttpOnly的作用是让浏览器禁止JavaScript访问该Cookie。这意味着document.cookie、XMLHttpRequest的withCredentials、甚至fetch的credentials: include都无法读取到这个Cookie的值。它只会在每次HTTP请求时由浏览器自动附加在Cookie请求头里。设置方式很简单在Java Spring Boot中ResponseCookie cookie ResponseCookie.from(SSO_TOKEN, token) .httpOnly(true) // 关键必须为true .secure(true) // 仅HTTPS传输 .path(/) // 覆盖整个域名路径 .maxAge(15 * 60) // 15分钟与Redis TTL一致 .domain(.example.com) // 注意开头的点表示匹配所有子域 .sameSite(Strict) // 防CSRF .build(); response.addHeader(Set-Cookie, cookie.toString());这里有个血泪教训httpOnlytrue之后前端就彻底失去了“主动刷新Token”的能力。有人会问“那用户长时间操作Token快过期了怎么办”答案是不要前端刷新要后端静默续期。我们在每个受保护接口的拦截器里只要校验通过就自动执行一次redisTemplate.expire(key, 15, TimeUnit.MINUTES)。用户无感安全不降级。3.2 SecureHTTPS的强制通行证Secure属性意味着这个Cookie只允许通过HTTPS协议传输。如果网站是HTTP协议浏览器会直接忽略这个Cookie拒绝设置。这看似增加了部署成本必须配SSL证书实则是把安全底线划得清清楚楚。我们曾在一个测试环境里为了省事用HTTP跑了一版SSO。结果某天运维同学发现大量用户反馈“登了又登总是跳回登录页”。排查半天发现是Chrome浏览器80版本后默认对localhost以外的所有HTTP站点都禁用了SecureCookie。用户在http://test.example.com登录Cookie因Secure属性被浏览器丢弃下次请求自然没带Token后端一看没认证又跳转回登录页——形成了死循环。解决方案只有一个测试环境也必须上HTTPS。我们用Lets Encrypt的免费证书配合Nginx反向代理10分钟搞定。别省这10分钟它省下的是一周的线上排查工时。3.3 SameSiteCSRF攻击的终结者SameSite属性是近年浏览器安全的重大升级它有三个值Strict、Lax、None。我们选的是Strict因为它对SSO场景最友好SameSiteStrict任何跨站请求都不发送该Cookie。比如用户在malicious-site.com里嵌了一个img srchttps://app.example.com/api/logout这个请求的Cookie头里绝不会带上SSO_TOKEN。CSRF攻击直接失效。SameSiteLax对GET请求如链接跳转放行Cookie对POST等危险方法仍拦截。适合普通网站但对SSO来说Lax可能导致某些子系统间的跳转丢失认证。SameSiteNone必须搭配Securetrue且明确允许跨站携带。这是为嵌入式应用如iframe准备的但我们内部系统不需要。选择Strict后我们遇到了一个兼容性问题老版本SafariiOS 12以下不支持SameSite会把整个Set-Cookie头解析失败导致Cookie设置失败。解决办法是做UA检测对不支持的客户端降级为LaxString userAgent request.getHeader(User-Agent); boolean supportsSameSite !userAgent.contains(Safari/) || userAgent.contains(Version/13) || userAgent.contains(Version/14); String sameSiteValue supportsSameSite ? Strict : Lax;安全从来不是非黑即白而是在风险与体验之间找到那个最务实的平衡点。4. Java拦截器的精巧编织从登录鉴权到上下文透传SSO的骨架搭好了但肉长在哪里答案是Java拦截器Interceptor。它不像Filter那样在Servlet容器最外层而是嵌在Spring MVC的调用链里既能拿到Controller的参数又能修改ModelAndView是处理认证逻辑的黄金位置。4.1 登录拦截器不止是放行与拦截我们的LoginInterceptor做了三件事远超一个简单的if (token null) { redirect(/login) }Token提取与标准化它会从Cookie、Header如X-SSO-Token、Query Param用于调试三个地方尝试获取Token并统一清洗去除空格、转义字符。这样即使前端调用方式不统一后端也能兜底。黑白名单快速过滤在Redis校验前先查一个本地ConcurrentHashMap缓存的“高频恶意IP黑名单”。这个缓存每5分钟从Redis同步一次里面存的是1分钟内尝试登录失败超过10次的IP。如果命中直接返回429 Too Many Requests连Redis都不碰——这是对抗暴力破解的第一道缓冲。用户上下文注入校验成功后不是简单地request.setAttribute(currentUser, user)而是用RequestContextHolder把用户信息绑定到当前请求线程public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token extractToken(request); SsoUser user ssoService.validateToken(token); if (user null) { response.sendRedirect(/login); return false; } // 注入线程上下文 RequestAttributes attrs RequestContextHolder.currentRequestAttributes(); attrs.setAttribute(CURRENT_USER, user, RequestAttributes.SCOPE_REQUEST); return true; } }这样后续任意Controller、Service里都能通过RequestContextHolder.currentRequestAttributes().getAttribute(CURRENT_USER, ...)拿到用户信息无需层层传递参数。这比Spring Security的SecurityContextHolder更轻量也更可控。4.2 权限拦截器基于角色的细粒度闸门有了用户下一步是判断“他能不能干这件事”。我们没用Shiro或Spring Security的ACLAccess Control List而是写了一个极简的PermissionInterceptorTarget(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String[] value() default {}; } // 拦截器里检查 public boolean preHandle(...) { SsoUser user getCurrentUser(request); HandlerMethod handler (HandlerMethod) handler; RequireRole annotation handler.getMethodAnnotation(RequireRole.class); if (annotation ! null) { SetString requiredRoles Set.of(annotation.value()); if (!Collections.disjoint(user.getRoles(), requiredRoles)) { // 角色匹配放行 } else { response.sendError(HttpServletResponse.SC_FORBIDDEN); return false; } } return true; }用法极其简单RestController public class ExamController { GetMapping(/exam/start) RequireRole({student, proctor}) // 学生和监考老师都能进 public ResponseEntity startExam(RequestParam String examId) { // ... } PostMapping(/exam/submit) RequireRole({student}) // 只有学生能提交 public ResponseEntity submitAnswer(...) { // ... } }这个设计的妙处在于权限校验逻辑和业务逻辑完全解耦。Controller只管“做什么”拦截器只管“谁可以做”改权限不用动一行业务代码。上线后教务处临时要求“实验课助教也能查看考卷”我们只改了一个注解5分钟上线。4.3 全局异常处理器把错误变成用户体验拦截器里抛出的异常如果直接打到前端就是一堆500 Internal Server Error和堆栈日志。我们用ControllerAdvice统一捕获ControllerAdvice public class SsoExceptionHandler { ExceptionHandler(SsoTokenExpiredException.class) ResponseBody public ResponseEntityMapString, Object handleExpired( SsoTokenExpiredException e, HttpServletRequest request) { MapString, Object result new HashMap(); result.put(code, 401); result.put(message, 登录已过期请重新登录); result.put(redirectUrl, /login?from URLEncoder.encode(request.getRequestURL().toString(), UTF-8)); return ResponseEntity.status(401).body(result); } ExceptionHandler(SsoForbiddenException.class) ResponseBody public ResponseEntityMapString, Object handleForbidden(...) { // 返回403带友好提示 } }关键是redirectUrl参数它把用户当前想访问的页面URL存下来登录成功后自动跳转回去。学生点开“我的成绩单”发现过期了重新登录后页面自动回到成绩单页而不是卡在登录页——这就是细节决定体验。实操心得拦截器的order顺序很重要。我们把LoginInterceptor设为Ordered.HIGHEST_PRECEDENCE 1最高优先级确保它第一个执行PermissionInterceptor设为Ordered.HIGHEST_PRECEDENCE 2紧随其后。如果顺序错了可能出现“还没登录就去校验权限”的荒诞场景。5. 真实压测与故障复盘Redis连接池、Cookie大小与跨域陷阱方案设计得再完美不经过真实流量的锤炼都是纸上谈兵。我们用JMeter对SSO链路做了三轮压测峰值QPS达到1200过程中暴露出三个典型问题每一个都值得写进团队Wiki。5.1 Redis连接池耗尽不是Redis慢是客户端没配好第一轮压测QPS刚到800后端就开始大量报Cannot get Jedis connection。监控显示Redis服务器CPU不到30%内存充足网络延迟稳定在0.2ms。问题出在Java客户端的连接池配置上。我们用的是LettuceSpring Boot 2.3默认初始配置是spring: redis: lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0这个配置在日常流量下没问题但在高并发下8个连接瞬间被占满新请求只能排队等待超时后抛异常。解决方案是根据公式调整max-active ≈ QPS × 平均Redis操作耗时秒× 安全系数1.5实测平均GET操作耗时1.2msQPS峰值1200计算得1200 × 0.0012 × 1.5 ≈ 2.16取整为32。最终配置spring: redis: lettuce: pool: max-active: 32 max-idle: 32 min-idle: 8 # 预热避免冷启动抖动 max-wait: 1000 # 等待连接的最大毫秒数超时抛异常不阻塞调整后连接池再没耗尽过。记住Redis服务器的性能永远受限于客户端连接池的配置。别迷信“Redis很快”慢的往往是你的Java代码。5.2 Cookie超长32字节Token 用户信息 浏览器拒绝第二轮压测部分用户主要是Chrome登录后无法跳转F12看Network发现Set-Cookie头被截断。抓包分析原来我们把用户昵称、头像URL、部门信息全塞进了Cookie的value里导致单个Cookie超过4096字节。而Chrome对单个Cookie的大小限制是4096字节超了就直接丢弃。根治办法Cookie里只存Token所有用户信息都存在Redis里。我们之前已经这么做了但前端同学为了“减少一次API调用”在登录成功后又用document.cookie手动写了一个userInfo的Cookie这就造成了冗余和超长。解决方案是后端严格控制Set-Cookie头只发SSO_TOKEN一个前端所有用户信息统一通过/api/current-user接口获取该接口走SSO校验返回JSON接口响应加Cache-Control: no-store禁止浏览器缓存。这样Cookie体积稳定在SSO_TOKENxxxxxxxxxx约50字符毫无压力。5.3 跨域子系统的Cookie共享Nginx的proxy_cookie_domain是救命稻草第三轮压测我们把实验预约系统lab.example.com和成绩系统score.example.com都接入SSO发现从lab跳转到score时Cookie没自动带上。抓包一看score系统的响应头里Set-Cookie的Domain是lab.example.com而不是.example.com。原因是两个系统由不同Nginx实例反向代理lab系统的Nginx配置里漏了这一行# 在lab系统的location块里 proxy_cookie_domain ~^www\.example\.com$ .example.com; proxy_cookie_domain ~^lab\.example\.com$ .example.com;proxy_cookie_domain指令的作用是重写上游Java后端返回的Set-Cookie头里的Domain属性。Java后端生成的Cookie Domain是lab.example.comNginx把它改成.example.com这样浏览器才会在score.example.com的请求里自动带上这个Cookie。这个坑我们踩了整整一天。教训是所有反向代理层都必须显式配置proxy_cookie_domain且值必须是根域名前加点.example.com。少一个点SSO就失效。故障复盘总结SSO的稳定性70%取决于基础设施配置Nginx、Redis客户端20%取决于代码逻辑拦截器、Token管理10%才是算法或协议本身。别总盯着Java代码多看看你的Nginx配置文件和Redis监控面板。6. 从SSO到SSO扩展单点登出与多因素认证的平滑路径这套“RedisCookie”方案跑稳后教务处提出了新需求“现在学生登出一个系统其他系统还得手动登出能不能一点全退”还有导师问“我们有些管理员账号能不能加个短信验证码”这两个需求都不需要推翻重来而是沿着现有架构做增量式演进。6.1 单点登出SLO广播式通知的轻量实现单点登出的核心难点是“如何通知所有已登录的子系统把当前用户的Token作废”。我们没用消息队列Kafka/RabbitMQ因为会引入新组件增加运维负担。而是采用Redis的Pub/Sub机制登出时发布事件用户在app.example.com点击退出后端除了删Redis Key、加黑名单还执行redisTemplate.convertAndSend(sso:logout:channel, {\userId\:\U2023001\,\source\:\app\});各子系统订阅频道所有接入SSO的Java应用启动时都创建一个RedisMessageListenerContainer监听sso:logout:channel。收到消息后立即执行// 从消息里解析userId批量删除该用户所有Token SetString tokens redisTemplate.keys(token:*: userId); if (!tokens.isEmpty()) { redisTemplate.delete(tokens); }这里用keys命令是有风险的O(N)复杂度所以我们在Token Key设计时就约定前缀为token:U2023001:xxx这样keys能快速定位。生产环境建议用SCAN替代但对我们几千用户的规模keys够用。前端同步清理Cookie各子系统收到登出通知后除了删Redis还要向前端返回一个特殊的Set-Cookie头把SSO_TOKEN的Max-Age设为0强制浏览器删除ResponseCookie expiredCookie ResponseCookie.from(SSO_TOKEN, ) .httpOnly(true) .secure(true) .path(/) .domain(.example.com) .maxAge(0) // 关键设为0浏览器立即删除 .build(); response.addHeader(Set-Cookie, expiredCookie.toString());整个SLO流程从点击登出到所有系统退出实测平均耗时230ms完全在用户可接受范围内。没有中心化登出服务没有复杂协议就是Redis里一次发布、多次订阅。6.2 多因素认证MFA在登录流程中无缝插入验证码加短信验证码最容易想到的是“登录页多一步输入框”。但我们不想破坏现有登录体验。方案是只对高权限账号启用MFA且验证码在登录成功后、Token发放前触发。流程改造如下用户输入账号密码后端校验通过检查该用户roles是否包含admin或super_admin如果是不立即生成Token而是生成一个6位随机码存入RedisKey为mfa:U2023001过期5分钟调用短信网关把验证码发到用户预留手机号返回前端一个mfaRequired: true标志以及一个mfaId即U2023001前端跳转到MFA验证页用户输入验证码后端收到验证码用mfaId查Redis匹配则生成SSO Token否则返回错误。关键点在于MFA验证和SSO Token发放是两个独立的HTTP请求。这样做的好处是MFA逻辑可以独立部署、独立扩容不影响主登录链路。我们甚至把短信网关封装成一个独立的Spring Boot Starter其他项目想用加个依赖、配个key就行。最后分享一个小技巧在Redis里存MFA验证码时不要只存数字而是存一个Map{ code: 123456, used: false, createdAt: 1717023456000, ip: 192.168.1.105 }这样如果用户输错三次我们可以把used设为true直接锁定如果发现同一IP频繁请求可以结合ip字段做风控。安全永远是层层设防而不是寄希望于某一个环节。这套“RedisCookie”的SSO方案从立项到全量上线总共花了11天。它没有用上任何高大上的名词却实实在在解决了业务最痛的点。技术的价值不在于它多炫酷而在于它多靠谱。当你把每一个Set-Cookie头的参数都抠明白把每一次Redis的expire调用都算清楚把每一个Nginx的proxy_cookie_domain都配准确SSO就不再是PPT里的架构图而是每天稳稳托住业务的那双手。
1. 为什么“RedisCookie”成了SSO落地最稳的组合拳最近帮某高校实验室重构一套跨平台教学管理后台核心诉求就一条学生用学号密码在教务系统登录后点开实验预约系统、成绩查询模块、在线考试平台全程不用再输一遍账号密码。这听起来就是个标准的单点登录SSO场景。但真正动手时才发现市面上那些动辄几十页文档的OAuth2.0方案、SAML协议堆叠对一个只有3人维护、服务器资源有限的内部系统来说不是杀鸡用牛刀是直接把鸡和刀一起炖了。我们最终选了最朴素的路径Java后端 Redis缓存 浏览器Cookie。没有引入Spring Security OAuth2的全套依赖没碰JWT的签名验签链路甚至没动Nginx的反向代理配置。整个流程跑通后我盯着控制台里那行Login success, SSO token saved to Redis发了会儿呆——原来SSO的底层逻辑真可以这么轻。这个组合之所以“稳”关键在于它把问题拆解得足够干净Redis不是当数据库用而是当一个带过期时间的、全集群共享的“临时票据抽屉”。你生成一个随机字符串作为token把它和用户ID、基础权限信息一起塞进去设好15分钟过期就完事了。它不存密码不存敏感字段只存“此刻这个人是谁、能干啥”的快照。Cookie也不是随便写个Set-Cookie: tokenabc123就完事。它必须带HttpOnly防JS读取、Secure仅HTTPS传输、SameSiteStrict防CSRF这三个属性缺一不可。我试过漏掉HttpOnly前端同学随手写了个document.cookie就拿到了token当场被我拦住——这不是SSO这是给攻击者递钥匙。Java后端的角色是那个严格守门的“票据核验员”。每次请求进来它不查数据库只去Redis里找这个token对应的用户信息找不到401找到了但权限不够403一切正常放行并把用户上下文注入到当前线程里比如用ThreadLocal存CurrentUserContext。很多人一提SSO就默认要上中心化认证服务其实大可不必。当你面对的是几个同域下的子系统比如app.example.com、exam.example.com、score.example.com且它们都由同一套Java后端支撑时“RedisCookie”就是那个既不增加运维复杂度、又不会在高并发下崩盘的黄金解法。它不炫技但每一步都踩在真实业务的痛点上快、稳、易维护。提示这个方案的前提是所有子系统共享同一个根域名如.example.com这样才能让Cookie在多个子域间自动携带。如果系统分散在完全不同的域名下比如a.com和b.net这套方案就失效了得另寻他路。2. Token生命周期管理从生成、校验到自动续期的闭环设计SSO最怕的不是登录失败而是用户正填着表单突然弹出“登录已过期请重新登录”的提示。这种体验断层比一开始就不让登录还伤用户信任。所以Token的生命周期管理必须像设计交通信号灯一样精密——既要防超时又要避免频繁重登。2.1 Token生成随机性与唯一性的双重保障我们没用UUID也没用时间戳拼接。而是采用SecureRandom生成32字节的随机字节数组再用Base64Url编码注意是Url安全版本把和/换成-和_去掉末尾public static String generateToken() { SecureRandom random new SecureRandom(); byte[] bytes new byte[32]; random.nextBytes(bytes); return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes); }为什么不用UUID因为UUIDv4虽然随机但它的熵值信息量理论上限是122位而32字节的随机数是256位暴力碰撞难度呈指数级增长。更重要的是UUID有固定格式8-4-4-4-12攻击者一旦摸清规律可能针对性爆破。而纯随机字节Base64Url输出是32个字符的无规律字符串连长度都统一更难被模式识别。生成后Token不是直接扔进Redis。我们存的是一个结构化对象{ userId: U2023001, username: 张三, roles: [student, lab_member], loginTime: 1717023456000, lastAccessTime: 1717023456000, ipAddress: 192.168.1.105 }这个JSON串用Jackson序列化后存入RedisKey就是Token本身过期时间设为15分钟。注意lastAccessTime字段至关重要它是我们实现“滑动过期”的锚点。2.2 滑动过期机制用户不动Token也不死传统TTLTime-To-Live是“生成即倒计时”不管用户是否还在操作15分钟后一律作废。这显然不合理。我们的做法是每次成功校验Token后重置Redis中该Key的过期时间并更新lastAccessTime字段。校验逻辑伪代码如下public SsoUser validateToken(String token) { String json redisTemplate.opsForValue().get(token); if (json null) { return null; // Token不存在或已过期 } SsoUser user objectMapper.readValue(json, SsoUser.class); // 检查是否超过最大空闲时间比如30分钟 long idleTime System.currentTimeMillis() - user.getLastAccessTime(); if (idleTime 30 * 60 * 1000) { redisTemplate.delete(token); // 主动清理 return null; } // 更新最后访问时间并重置Redis过期时间 user.setLastAccessTime(System.currentTimeMillis()); redisTemplate.opsForValue().set(token, objectMapper.writeValueAsString(user), 15, TimeUnit.MINUTES); return user; }这里有两个关键阈值Redis TTL 15分钟这是物理层面的硬性过期防止Token无限续命。逻辑空闲超时 30分钟这是业务层面的软性限制只要用户30分钟内有过任何操作Token就一直有效。这个双阈值设计让用户体验丝滑学生连续刷题2小时Token自动续了8次他根本感觉不到后台在默默工作而如果他打开页面后去吃饭、回来看到登录页也只会觉得“哦太久没动安全起见重新登一下”而不是“刚填一半的表单没了”。2.3 Token主动注销不只是删Redis Key那么简单用户点击“退出登录”不能只删Redis里的Key就完事。我们遇到过真实案例A同学在图书馆电脑登了账号忘了点退出直接关机走人B同学接着用同一台电脑发现还能直接进系统——因为Cookie没清除Redis Key又被A同学的操作续了命。解决方案是引入“Token黑名单”。退出时除了删除Redis Key还要把该Token加进一个短期存在的黑名单// 退出逻辑 public void logout(String token) { // 1. 删除主Token redisTemplate.delete(token); // 2. 加入黑名单有效期5分钟覆盖可能的网络延迟 redisTemplate.opsForValue().set(blacklist: token, 1, 5, TimeUnit.MINUTES); } // 校验逻辑新增检查 public SsoUser validateToken(String token) { // ... 前面的校验步骤 // 新增检查是否在黑名单 if (redisTemplate.hasKey(blacklist: token)) { return null; } // ... 后续更新逻辑 }黑名单的存在时间5分钟很讲究太短如1秒网络抖动可能导致刚登出就又能登太长如30分钟用户真正想登出时反而要等很久。5分钟是经过压测后平衡安全与体验的结果——它足够覆盖一次HTTP请求的完整往返又不会让用户等得焦虑。注意黑名单本身也用Redis存储但用的是String类型而非Hash因为hasKey()操作在Redis里是O(1)复杂度而HGET在大数据量下可能退化。性能和安全永远要算这笔账。3. Cookie的安全防线HttpOnly、Secure与SameSite的实战取舍很多团队把SSO做崩不是败在Redis配置而是栽在Cookie的一行Set-Cookie头里。我见过最离谱的案例开发同学为了“方便调试”把HttpOnlyfalse结果前端一个console.log(document.cookie)就把所有用户的token打印在了控制台里——这已经不是漏洞是裸奔。3.1 HttpOnly第一道不可逾越的墙HttpOnly的作用是让浏览器禁止JavaScript访问该Cookie。这意味着document.cookie、XMLHttpRequest的withCredentials、甚至fetch的credentials: include都无法读取到这个Cookie的值。它只会在每次HTTP请求时由浏览器自动附加在Cookie请求头里。设置方式很简单在Java Spring Boot中ResponseCookie cookie ResponseCookie.from(SSO_TOKEN, token) .httpOnly(true) // 关键必须为true .secure(true) // 仅HTTPS传输 .path(/) // 覆盖整个域名路径 .maxAge(15 * 60) // 15分钟与Redis TTL一致 .domain(.example.com) // 注意开头的点表示匹配所有子域 .sameSite(Strict) // 防CSRF .build(); response.addHeader(Set-Cookie, cookie.toString());这里有个血泪教训httpOnlytrue之后前端就彻底失去了“主动刷新Token”的能力。有人会问“那用户长时间操作Token快过期了怎么办”答案是不要前端刷新要后端静默续期。我们在每个受保护接口的拦截器里只要校验通过就自动执行一次redisTemplate.expire(key, 15, TimeUnit.MINUTES)。用户无感安全不降级。3.2 SecureHTTPS的强制通行证Secure属性意味着这个Cookie只允许通过HTTPS协议传输。如果网站是HTTP协议浏览器会直接忽略这个Cookie拒绝设置。这看似增加了部署成本必须配SSL证书实则是把安全底线划得清清楚楚。我们曾在一个测试环境里为了省事用HTTP跑了一版SSO。结果某天运维同学发现大量用户反馈“登了又登总是跳回登录页”。排查半天发现是Chrome浏览器80版本后默认对localhost以外的所有HTTP站点都禁用了SecureCookie。用户在http://test.example.com登录Cookie因Secure属性被浏览器丢弃下次请求自然没带Token后端一看没认证又跳转回登录页——形成了死循环。解决方案只有一个测试环境也必须上HTTPS。我们用Lets Encrypt的免费证书配合Nginx反向代理10分钟搞定。别省这10分钟它省下的是一周的线上排查工时。3.3 SameSiteCSRF攻击的终结者SameSite属性是近年浏览器安全的重大升级它有三个值Strict、Lax、None。我们选的是Strict因为它对SSO场景最友好SameSiteStrict任何跨站请求都不发送该Cookie。比如用户在malicious-site.com里嵌了一个img srchttps://app.example.com/api/logout这个请求的Cookie头里绝不会带上SSO_TOKEN。CSRF攻击直接失效。SameSiteLax对GET请求如链接跳转放行Cookie对POST等危险方法仍拦截。适合普通网站但对SSO来说Lax可能导致某些子系统间的跳转丢失认证。SameSiteNone必须搭配Securetrue且明确允许跨站携带。这是为嵌入式应用如iframe准备的但我们内部系统不需要。选择Strict后我们遇到了一个兼容性问题老版本SafariiOS 12以下不支持SameSite会把整个Set-Cookie头解析失败导致Cookie设置失败。解决办法是做UA检测对不支持的客户端降级为LaxString userAgent request.getHeader(User-Agent); boolean supportsSameSite !userAgent.contains(Safari/) || userAgent.contains(Version/13) || userAgent.contains(Version/14); String sameSiteValue supportsSameSite ? Strict : Lax;安全从来不是非黑即白而是在风险与体验之间找到那个最务实的平衡点。4. Java拦截器的精巧编织从登录鉴权到上下文透传SSO的骨架搭好了但肉长在哪里答案是Java拦截器Interceptor。它不像Filter那样在Servlet容器最外层而是嵌在Spring MVC的调用链里既能拿到Controller的参数又能修改ModelAndView是处理认证逻辑的黄金位置。4.1 登录拦截器不止是放行与拦截我们的LoginInterceptor做了三件事远超一个简单的if (token null) { redirect(/login) }Token提取与标准化它会从Cookie、Header如X-SSO-Token、Query Param用于调试三个地方尝试获取Token并统一清洗去除空格、转义字符。这样即使前端调用方式不统一后端也能兜底。黑白名单快速过滤在Redis校验前先查一个本地ConcurrentHashMap缓存的“高频恶意IP黑名单”。这个缓存每5分钟从Redis同步一次里面存的是1分钟内尝试登录失败超过10次的IP。如果命中直接返回429 Too Many Requests连Redis都不碰——这是对抗暴力破解的第一道缓冲。用户上下文注入校验成功后不是简单地request.setAttribute(currentUser, user)而是用RequestContextHolder把用户信息绑定到当前请求线程public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token extractToken(request); SsoUser user ssoService.validateToken(token); if (user null) { response.sendRedirect(/login); return false; } // 注入线程上下文 RequestAttributes attrs RequestContextHolder.currentRequestAttributes(); attrs.setAttribute(CURRENT_USER, user, RequestAttributes.SCOPE_REQUEST); return true; } }这样后续任意Controller、Service里都能通过RequestContextHolder.currentRequestAttributes().getAttribute(CURRENT_USER, ...)拿到用户信息无需层层传递参数。这比Spring Security的SecurityContextHolder更轻量也更可控。4.2 权限拦截器基于角色的细粒度闸门有了用户下一步是判断“他能不能干这件事”。我们没用Shiro或Spring Security的ACLAccess Control List而是写了一个极简的PermissionInterceptorTarget(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String[] value() default {}; } // 拦截器里检查 public boolean preHandle(...) { SsoUser user getCurrentUser(request); HandlerMethod handler (HandlerMethod) handler; RequireRole annotation handler.getMethodAnnotation(RequireRole.class); if (annotation ! null) { SetString requiredRoles Set.of(annotation.value()); if (!Collections.disjoint(user.getRoles(), requiredRoles)) { // 角色匹配放行 } else { response.sendError(HttpServletResponse.SC_FORBIDDEN); return false; } } return true; }用法极其简单RestController public class ExamController { GetMapping(/exam/start) RequireRole({student, proctor}) // 学生和监考老师都能进 public ResponseEntity startExam(RequestParam String examId) { // ... } PostMapping(/exam/submit) RequireRole({student}) // 只有学生能提交 public ResponseEntity submitAnswer(...) { // ... } }这个设计的妙处在于权限校验逻辑和业务逻辑完全解耦。Controller只管“做什么”拦截器只管“谁可以做”改权限不用动一行业务代码。上线后教务处临时要求“实验课助教也能查看考卷”我们只改了一个注解5分钟上线。4.3 全局异常处理器把错误变成用户体验拦截器里抛出的异常如果直接打到前端就是一堆500 Internal Server Error和堆栈日志。我们用ControllerAdvice统一捕获ControllerAdvice public class SsoExceptionHandler { ExceptionHandler(SsoTokenExpiredException.class) ResponseBody public ResponseEntityMapString, Object handleExpired( SsoTokenExpiredException e, HttpServletRequest request) { MapString, Object result new HashMap(); result.put(code, 401); result.put(message, 登录已过期请重新登录); result.put(redirectUrl, /login?from URLEncoder.encode(request.getRequestURL().toString(), UTF-8)); return ResponseEntity.status(401).body(result); } ExceptionHandler(SsoForbiddenException.class) ResponseBody public ResponseEntityMapString, Object handleForbidden(...) { // 返回403带友好提示 } }关键是redirectUrl参数它把用户当前想访问的页面URL存下来登录成功后自动跳转回去。学生点开“我的成绩单”发现过期了重新登录后页面自动回到成绩单页而不是卡在登录页——这就是细节决定体验。实操心得拦截器的order顺序很重要。我们把LoginInterceptor设为Ordered.HIGHEST_PRECEDENCE 1最高优先级确保它第一个执行PermissionInterceptor设为Ordered.HIGHEST_PRECEDENCE 2紧随其后。如果顺序错了可能出现“还没登录就去校验权限”的荒诞场景。5. 真实压测与故障复盘Redis连接池、Cookie大小与跨域陷阱方案设计得再完美不经过真实流量的锤炼都是纸上谈兵。我们用JMeter对SSO链路做了三轮压测峰值QPS达到1200过程中暴露出三个典型问题每一个都值得写进团队Wiki。5.1 Redis连接池耗尽不是Redis慢是客户端没配好第一轮压测QPS刚到800后端就开始大量报Cannot get Jedis connection。监控显示Redis服务器CPU不到30%内存充足网络延迟稳定在0.2ms。问题出在Java客户端的连接池配置上。我们用的是LettuceSpring Boot 2.3默认初始配置是spring: redis: lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0这个配置在日常流量下没问题但在高并发下8个连接瞬间被占满新请求只能排队等待超时后抛异常。解决方案是根据公式调整max-active ≈ QPS × 平均Redis操作耗时秒× 安全系数1.5实测平均GET操作耗时1.2msQPS峰值1200计算得1200 × 0.0012 × 1.5 ≈ 2.16取整为32。最终配置spring: redis: lettuce: pool: max-active: 32 max-idle: 32 min-idle: 8 # 预热避免冷启动抖动 max-wait: 1000 # 等待连接的最大毫秒数超时抛异常不阻塞调整后连接池再没耗尽过。记住Redis服务器的性能永远受限于客户端连接池的配置。别迷信“Redis很快”慢的往往是你的Java代码。5.2 Cookie超长32字节Token 用户信息 浏览器拒绝第二轮压测部分用户主要是Chrome登录后无法跳转F12看Network发现Set-Cookie头被截断。抓包分析原来我们把用户昵称、头像URL、部门信息全塞进了Cookie的value里导致单个Cookie超过4096字节。而Chrome对单个Cookie的大小限制是4096字节超了就直接丢弃。根治办法Cookie里只存Token所有用户信息都存在Redis里。我们之前已经这么做了但前端同学为了“减少一次API调用”在登录成功后又用document.cookie手动写了一个userInfo的Cookie这就造成了冗余和超长。解决方案是后端严格控制Set-Cookie头只发SSO_TOKEN一个前端所有用户信息统一通过/api/current-user接口获取该接口走SSO校验返回JSON接口响应加Cache-Control: no-store禁止浏览器缓存。这样Cookie体积稳定在SSO_TOKENxxxxxxxxxx约50字符毫无压力。5.3 跨域子系统的Cookie共享Nginx的proxy_cookie_domain是救命稻草第三轮压测我们把实验预约系统lab.example.com和成绩系统score.example.com都接入SSO发现从lab跳转到score时Cookie没自动带上。抓包一看score系统的响应头里Set-Cookie的Domain是lab.example.com而不是.example.com。原因是两个系统由不同Nginx实例反向代理lab系统的Nginx配置里漏了这一行# 在lab系统的location块里 proxy_cookie_domain ~^www\.example\.com$ .example.com; proxy_cookie_domain ~^lab\.example\.com$ .example.com;proxy_cookie_domain指令的作用是重写上游Java后端返回的Set-Cookie头里的Domain属性。Java后端生成的Cookie Domain是lab.example.comNginx把它改成.example.com这样浏览器才会在score.example.com的请求里自动带上这个Cookie。这个坑我们踩了整整一天。教训是所有反向代理层都必须显式配置proxy_cookie_domain且值必须是根域名前加点.example.com。少一个点SSO就失效。故障复盘总结SSO的稳定性70%取决于基础设施配置Nginx、Redis客户端20%取决于代码逻辑拦截器、Token管理10%才是算法或协议本身。别总盯着Java代码多看看你的Nginx配置文件和Redis监控面板。6. 从SSO到SSO扩展单点登出与多因素认证的平滑路径这套“RedisCookie”方案跑稳后教务处提出了新需求“现在学生登出一个系统其他系统还得手动登出能不能一点全退”还有导师问“我们有些管理员账号能不能加个短信验证码”这两个需求都不需要推翻重来而是沿着现有架构做增量式演进。6.1 单点登出SLO广播式通知的轻量实现单点登出的核心难点是“如何通知所有已登录的子系统把当前用户的Token作废”。我们没用消息队列Kafka/RabbitMQ因为会引入新组件增加运维负担。而是采用Redis的Pub/Sub机制登出时发布事件用户在app.example.com点击退出后端除了删Redis Key、加黑名单还执行redisTemplate.convertAndSend(sso:logout:channel, {\userId\:\U2023001\,\source\:\app\});各子系统订阅频道所有接入SSO的Java应用启动时都创建一个RedisMessageListenerContainer监听sso:logout:channel。收到消息后立即执行// 从消息里解析userId批量删除该用户所有Token SetString tokens redisTemplate.keys(token:*: userId); if (!tokens.isEmpty()) { redisTemplate.delete(tokens); }这里用keys命令是有风险的O(N)复杂度所以我们在Token Key设计时就约定前缀为token:U2023001:xxx这样keys能快速定位。生产环境建议用SCAN替代但对我们几千用户的规模keys够用。前端同步清理Cookie各子系统收到登出通知后除了删Redis还要向前端返回一个特殊的Set-Cookie头把SSO_TOKEN的Max-Age设为0强制浏览器删除ResponseCookie expiredCookie ResponseCookie.from(SSO_TOKEN, ) .httpOnly(true) .secure(true) .path(/) .domain(.example.com) .maxAge(0) // 关键设为0浏览器立即删除 .build(); response.addHeader(Set-Cookie, expiredCookie.toString());整个SLO流程从点击登出到所有系统退出实测平均耗时230ms完全在用户可接受范围内。没有中心化登出服务没有复杂协议就是Redis里一次发布、多次订阅。6.2 多因素认证MFA在登录流程中无缝插入验证码加短信验证码最容易想到的是“登录页多一步输入框”。但我们不想破坏现有登录体验。方案是只对高权限账号启用MFA且验证码在登录成功后、Token发放前触发。流程改造如下用户输入账号密码后端校验通过检查该用户roles是否包含admin或super_admin如果是不立即生成Token而是生成一个6位随机码存入RedisKey为mfa:U2023001过期5分钟调用短信网关把验证码发到用户预留手机号返回前端一个mfaRequired: true标志以及一个mfaId即U2023001前端跳转到MFA验证页用户输入验证码后端收到验证码用mfaId查Redis匹配则生成SSO Token否则返回错误。关键点在于MFA验证和SSO Token发放是两个独立的HTTP请求。这样做的好处是MFA逻辑可以独立部署、独立扩容不影响主登录链路。我们甚至把短信网关封装成一个独立的Spring Boot Starter其他项目想用加个依赖、配个key就行。最后分享一个小技巧在Redis里存MFA验证码时不要只存数字而是存一个Map{ code: 123456, used: false, createdAt: 1717023456000, ip: 192.168.1.105 }这样如果用户输错三次我们可以把used设为true直接锁定如果发现同一IP频繁请求可以结合ip字段做风控。安全永远是层层设防而不是寄希望于某一个环节。这套“RedisCookie”的SSO方案从立项到全量上线总共花了11天。它没有用上任何高大上的名词却实实在在解决了业务最痛的点。技术的价值不在于它多炫酷而在于它多靠谱。当你把每一个Set-Cookie头的参数都抠明白把每一次Redis的expire调用都算清楚把每一个Nginx的proxy_cookie_domain都配准确SSO就不再是PPT里的架构图而是每天稳稳托住业务的那双手。
