一位摸鱼二年半的Java程序员，头发只剩二根半，但SSO的坑一根头发都没白掉！
面试官一推眼镜，嘴角微扬：“看你简历写着‘参与系统架构设计’——那聊聊单点登录（SSO）怎么做的吧？”
菜鸟可能瞬间卡壳，脑中飘过“登录一次，处处通行？”，而我这种老油条——微微一笑，心底默念：“来了来了，又到了我表演真正技术的时刻！”
一、别一上来就讲技术！先怼场景！
面试不是背八股，答SSO之前，先反问一句：
“您问的是内网系统之间？外网多域名系统？还是允许第三方接入的开放平台？”
- •内网同域：Cookie共享，设置domain=.company.com，简单但局限极大
- •外网跨域：Token + 认证中心，这是主流！
- •第三方接入：OAuth2.0授权框架，比如微信登录、GitHub登录
不说场景直接讲方案＝耍流氓！
你得让面试官觉得——你思考问题是从实际出发的，不是背诵教材！
二、原理核心：一张“通行证”闯天下！
SSO本质就一句话：一个中心管认证，多个系统皆信任
（嘴动画图开始～）
-
1.用户访问系统A → 未登录？重定向到认证中心（SSO Server）
-
2.认证中心逼你登录 → 成功后生成Token（存Redis或JWT），并种Cookie在认证域名下
-
3.回跳系统A → 携Token参数，A系统后台拿Token去认证中心验证 → 验证成功，本地Session/Cookie安排！
-
4.用户再访问系统B → 未登录？重定向到认证中心
- •这里最关键！认证中心怎么知道已登录？
因为之前登录时，认证中心自己的域名下已经种了Cookie！所以这次跳转过去，浏览器自动带上这个Cookie！认证中心一看Cookie有效，就直接放行——无需再登录！
- •这里最关键！认证中心怎么知道已登录？
-
5.系统B拿到Token，验签通过，建立会话，完成登录！
三、实现姿势：Spring全家桶狂喜！
| 方案 | 适用场景 | 技术栈 | 缺点 |
|---|---|---|---|
| Cookie共享 | 同父域名 | Nginx + Tomcat Session | 跨域彻底玩完 |
| Token+认证中心 | 跨域系统 | Spring Boot + Redis + JWT | 要实现注销稍复杂 |
| OAuth2.0 / OIDC | 第三方授权 | Spring Security OAuth2 | 流程复杂，适合开放平台 |
主流选择：Token + 认证中心
- •认证中心：Spring Boot + Spring Security
- •Token：JWT（无状态）或Redis存储SessionId（有状态）
- •网关：Nginx/Spring Cloud Gateway统一拦截认证
四、致命问题：注销怎么办？Token失效怎么搞？
面试官最爱追问的坑点！
-
单点注销（SLO）怎么实现？
- •用户点击注销，认证中心清除自身登录状态（删RedisToken或拉黑JWT）
- •然后通知所有子系统回调注销接口（前端跳转 or 后端异步调用）
- •各子系统清除本地Session/Cookie
-
Token失效策略
- •JWT：设置exp过期时间 + 黑名单机制（Redis记录失效Token）
- •RedisToken：直接delete Key，最快最暴力！
五、终极奥义：为什么非得用SSO？
别傻傻说“为了用户少输密码”！得上升维度：
- •用户体验：一次登录，全线畅通（用户爽）
- •安全管控：统一认证、统一审计、统一登出（安全团队爽）
- •开发效率：账号体系解耦，各系统专注业务（开发爽）
- •权限集中：RBAC权限模型统一管理（运维爽）
回答模板（背下来，不失风度！）
我们用的是基于Token的SSO方案，搭建独立认证中心，登录后生成全局Token存Redis，子系统通过重定向和Token验证实现互通。注销时通过回调通知各系统清理本地状态。另外针对跨域问题，我们采用Spring Security OAuth2做了授权服务支撑。”
说完停顿一下，眼神坚定，补充一句：“不过具体方案还得看系统是内网还是互联网环境。
最后提醒：别虚！面试官可能也没真正实现过！
你越淡定，他越觉得你深不可测。
反正——能把流程讲明白、把坑点讲清楚、把场景分细致，你就赢了！
下次面试，说到SSO，请你嘴角上扬、眼神自信，让面试官怀疑：“这秃子……怕是来替代我的吧？”
