原理与实现：从Cookie共享到JWT方案)
1. 单点登录SSO的本质与价值第一次接触单点登录是在2015年负责一个企业级ERP系统整合项目时。当时公司有OA、CRM、财务系统等8个独立系统每个系统都需要单独登录员工每天要记住多套账号密码IT部门每年要处理数百起密码重置请求。直到我们引入SSO方案后这些痛点才真正得到解决。单点登录Single Sign-On本质上是一种身份认证的集中化管理方案。它的核心思想是将认证逻辑从各个业务系统中剥离出来交由专门的认证服务统一处理。这种架构带来的最直接好处就是用户体验的提升——用户只需一次登录即可访问所有互信系统无需反复输入凭证。从技术实现角度看SSO系统通常包含三个关键组件认证中心SSO Server负责用户身份验证的核心服务业务系统Service Provider依赖认证中心验证用户身份的各个应用令牌服务Token Service生成和验证身份凭证的机制提示在设计SSO系统时务必将认证逻辑与业务逻辑彻底解耦。认证中心应该只负责身份验证不包含任何业务规则。2. 同域下的SSO实现方案2.1 Cookie共享机制在同域名环境下如a.com及其子域名最简单的SSO实现方式是使用顶域Cookie。当用户在sso.a.com完成登录后服务端设置Cookie的domain属性为.a.com这样所有子域名都能读取到这个Cookie。// Java示例设置顶域Cookie Cookie cookie new Cookie(sso_token, token); cookie.setDomain(.a.com); cookie.setPath(/); response.addCookie(cookie);这种方案的优点是实现简单但存在两个关键限制所有系统必须使用相同的主域名浏览器对Cookie数量的限制可能成为瓶颈通常每个域名最多50个Cookie2.2 Session共享方案要实现真正的状态共享需要解决Session同步问题。常见的解决方案包括Session复制通过组播方式将Session变更同步到所有服务器持久化到数据库将会话数据存储到MySQL等关系型数据库集中式缓存使用Redis或Memcached作为共享存储我们项目最终选择了Redis方案主要基于以下考虑读写性能优异10万 QPS内置过期机制无需额外维护支持集群部署可用性高# Python连接Redis示例 import redis pool redis.ConnectionPool(hostredis-cluster, port6379, db0) r redis.Redis(connection_poolpool) r.setex(session:session_id, 3600, user_data) # 设置1小时过期3. 跨域SSO的实现策略3.1 CAS协议详解当系统处于不同域名时就需要采用更复杂的跨域方案。Central Authentication ServiceCAS是最成熟的SSO协议之一其核心流程包括服务票据Service Ticket一次性使用的临时凭证票据验证Ticket Validation业务系统与认证中心的交互验证全局会话Global Session维护用户在认证中心的登录状态典型的CAS登录时序如下用户访问app1.com被重定向到sso.com/login在sso.com完成认证后生成ST并重定向回app1.com?ticketST-123app1.com后台向sso.com验证ST有效性验证通过后建立局部会话3.2 JWT替代方案在现代架构中JSON Web TokenJWT也常被用于跨域SSO。与CAS相比JWT具有无状态、易于扩展的优点。一个典型的JWT SSO流程sequenceDiagram participant User participant App1 participant SSO User-App1: 访问受限资源 App1-User: 重定向到SSO User-SSO: 提交凭证 SSO-User: 返回含JWT的URL重定向 User-App1: 携带JWT访问 App1-SSO: 验证JWT签名可选 App1-User: 返回资源JWT的核心优势在于自包含用户信息直接编码在token中签名验证服务端无需存储会话状态标准化支持跨语言、跨平台使用// 生成JWT的Node.js示例 const jwt require(jsonwebtoken); const token jwt.sign( { userId: 123, role: admin }, your-256-bit-secret, { expiresIn: 1h } );4. 企业级SSO实践要点4.1 安全防护措施在金融行业SSO项目中我们总结了以下安全实践令牌防篡改使用HS256或RS256强签名算法传输安全强制HTTPS禁止明文传输token时效控制access_token设置短有效期如30分钟refresh_token设置长有效期如7天绑定设备将token与设备指纹关联防止横向移动4.2 性能优化方案当用户量达到百万级时SSO系统可能面临性能挑战。我们的优化经验包括多级缓存本地缓存分布式缓存组合连接池优化数据库和Redis连接池的合理配置异步日志避免同步写日志造成的I/O阻塞水平扩展认证服务无状态化设计// Spring Boot连接池配置示例 spring.datasource.hikari.maximum-pool-size20 spring.datasource.hikari.connection-timeout30000 spring.redis.lettuce.pool.max-active504.3 容灾与降级为确保SSO系统高可用必须设计完善的容灾方案多活部署跨机房部署认证中心熔断机制当SSO不可用时降级为本地认证流量切换DNS负载均衡快速切换故障节点数据同步MySQL主从同步Redis集群5. 常见问题排查指南5.1 Cookie设置失败现象登录成功后业务系统无法获取认证Cookie检查domain设置是否包含前导点如.domain.com确认Path属性设置为/验证SameSite属性配置建议Lax模式5.2 跨域资源共享问题现象AJAX请求无法携带认证信息确保服务端设置Access-Control-Allow-Credentials: true配置Access-Control-Allow-Origin为具体域名不能为*前端axios需要设置withCredentials: true// axios跨域带凭证配置 axios.get(https://api.example.com, { withCredentials: true });5.3 会话失效异常现象用户频繁被踢出登录检查各系统时钟是否同步NTP服务验证token过期时间设置是否合理排查Redis集群是否发生主从切换6. 技术选型建议根据多年项目经验不同场景下的SSO选型建议场景特征推荐方案典型案例同域名系统Cookie共享Session共享企业内部门户跨域名但可控CAS协议大学校园系统现代前后端分离JWTOAuth2.0互联网SaaS产品高安全要求SAML2.0金融机构、政府系统对于新项目我个人更倾向采用JWT方案因为它天然支持移动端易于实现微服务间的认证社区生态完善各种语言SDK齐全在最近的一个物联网平台项目中我们采用JWT双token机制access_tokenrefresh_token既保证了安全性又提供了良好的用户体验。access_token有效期设置为15分钟refresh_token为7天通过Redis维护token黑名单实现了灵活的安全控制。
1. 单点登录SSO的本质与价值第一次接触单点登录是在2015年负责一个企业级ERP系统整合项目时。当时公司有OA、CRM、财务系统等8个独立系统每个系统都需要单独登录员工每天要记住多套账号密码IT部门每年要处理数百起密码重置请求。直到我们引入SSO方案后这些痛点才真正得到解决。单点登录Single Sign-On本质上是一种身份认证的集中化管理方案。它的核心思想是将认证逻辑从各个业务系统中剥离出来交由专门的认证服务统一处理。这种架构带来的最直接好处就是用户体验的提升——用户只需一次登录即可访问所有互信系统无需反复输入凭证。从技术实现角度看SSO系统通常包含三个关键组件认证中心SSO Server负责用户身份验证的核心服务业务系统Service Provider依赖认证中心验证用户身份的各个应用令牌服务Token Service生成和验证身份凭证的机制提示在设计SSO系统时务必将认证逻辑与业务逻辑彻底解耦。认证中心应该只负责身份验证不包含任何业务规则。2. 同域下的SSO实现方案2.1 Cookie共享机制在同域名环境下如a.com及其子域名最简单的SSO实现方式是使用顶域Cookie。当用户在sso.a.com完成登录后服务端设置Cookie的domain属性为.a.com这样所有子域名都能读取到这个Cookie。// Java示例设置顶域Cookie Cookie cookie new Cookie(sso_token, token); cookie.setDomain(.a.com); cookie.setPath(/); response.addCookie(cookie);这种方案的优点是实现简单但存在两个关键限制所有系统必须使用相同的主域名浏览器对Cookie数量的限制可能成为瓶颈通常每个域名最多50个Cookie2.2 Session共享方案要实现真正的状态共享需要解决Session同步问题。常见的解决方案包括Session复制通过组播方式将Session变更同步到所有服务器持久化到数据库将会话数据存储到MySQL等关系型数据库集中式缓存使用Redis或Memcached作为共享存储我们项目最终选择了Redis方案主要基于以下考虑读写性能优异10万 QPS内置过期机制无需额外维护支持集群部署可用性高# Python连接Redis示例 import redis pool redis.ConnectionPool(hostredis-cluster, port6379, db0) r redis.Redis(connection_poolpool) r.setex(session:session_id, 3600, user_data) # 设置1小时过期3. 跨域SSO的实现策略3.1 CAS协议详解当系统处于不同域名时就需要采用更复杂的跨域方案。Central Authentication ServiceCAS是最成熟的SSO协议之一其核心流程包括服务票据Service Ticket一次性使用的临时凭证票据验证Ticket Validation业务系统与认证中心的交互验证全局会话Global Session维护用户在认证中心的登录状态典型的CAS登录时序如下用户访问app1.com被重定向到sso.com/login在sso.com完成认证后生成ST并重定向回app1.com?ticketST-123app1.com后台向sso.com验证ST有效性验证通过后建立局部会话3.2 JWT替代方案在现代架构中JSON Web TokenJWT也常被用于跨域SSO。与CAS相比JWT具有无状态、易于扩展的优点。一个典型的JWT SSO流程sequenceDiagram participant User participant App1 participant SSO User-App1: 访问受限资源 App1-User: 重定向到SSO User-SSO: 提交凭证 SSO-User: 返回含JWT的URL重定向 User-App1: 携带JWT访问 App1-SSO: 验证JWT签名可选 App1-User: 返回资源JWT的核心优势在于自包含用户信息直接编码在token中签名验证服务端无需存储会话状态标准化支持跨语言、跨平台使用// 生成JWT的Node.js示例 const jwt require(jsonwebtoken); const token jwt.sign( { userId: 123, role: admin }, your-256-bit-secret, { expiresIn: 1h } );4. 企业级SSO实践要点4.1 安全防护措施在金融行业SSO项目中我们总结了以下安全实践令牌防篡改使用HS256或RS256强签名算法传输安全强制HTTPS禁止明文传输token时效控制access_token设置短有效期如30分钟refresh_token设置长有效期如7天绑定设备将token与设备指纹关联防止横向移动4.2 性能优化方案当用户量达到百万级时SSO系统可能面临性能挑战。我们的优化经验包括多级缓存本地缓存分布式缓存组合连接池优化数据库和Redis连接池的合理配置异步日志避免同步写日志造成的I/O阻塞水平扩展认证服务无状态化设计// Spring Boot连接池配置示例 spring.datasource.hikari.maximum-pool-size20 spring.datasource.hikari.connection-timeout30000 spring.redis.lettuce.pool.max-active504.3 容灾与降级为确保SSO系统高可用必须设计完善的容灾方案多活部署跨机房部署认证中心熔断机制当SSO不可用时降级为本地认证流量切换DNS负载均衡快速切换故障节点数据同步MySQL主从同步Redis集群5. 常见问题排查指南5.1 Cookie设置失败现象登录成功后业务系统无法获取认证Cookie检查domain设置是否包含前导点如.domain.com确认Path属性设置为/验证SameSite属性配置建议Lax模式5.2 跨域资源共享问题现象AJAX请求无法携带认证信息确保服务端设置Access-Control-Allow-Credentials: true配置Access-Control-Allow-Origin为具体域名不能为*前端axios需要设置withCredentials: true// axios跨域带凭证配置 axios.get(https://api.example.com, { withCredentials: true });5.3 会话失效异常现象用户频繁被踢出登录检查各系统时钟是否同步NTP服务验证token过期时间设置是否合理排查Redis集群是否发生主从切换6. 技术选型建议根据多年项目经验不同场景下的SSO选型建议场景特征推荐方案典型案例同域名系统Cookie共享Session共享企业内部门户跨域名但可控CAS协议大学校园系统现代前后端分离JWTOAuth2.0互联网SaaS产品高安全要求SAML2.0金融机构、政府系统对于新项目我个人更倾向采用JWT方案因为它天然支持移动端易于实现微服务间的认证社区生态完善各种语言SDK齐全在最近的一个物联网平台项目中我们采用JWT双token机制access_tokenrefresh_token既保证了安全性又提供了良好的用户体验。access_token有效期设置为15分钟refresh_token为7天通过Redis维护token黑名单实现了灵活的安全控制。
