一位摸鱼二年半的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,请你嘴角上扬、眼神自信,让面试官怀疑:"这秃子......怕是来替代我的吧?"