沉默是金，总会发光

大家好，我是沉默




单点登录（Single Sign-On，简称SSO）就像企业应用的万能钥匙，让用户用一组账号密码，一次登录，就能畅游多个相关系统，不用反复输入密码。对于有多个应用的企业，这不仅极大提升用户体验，还能降低管理密码的麻烦和风险。


今天，我们用最通俗的语言，深度剖析几种主流SSO方案，帮你选对技术，快速落地！


-01-

基于Cookie-Session的传统SSO 

原理：

想象一下，你在公司大厦大门口登记进去了，门卫给你发了个带有编号的腕带（Session ID）。你走进不同的办公室时，只要出示腕带，保安都知道你是合法员工，不用再重新登记。

技术上，用户登录SSO服务器后，服务器保存登录状态在服务端Session里，并把Session ID放进顶级域名下的Cookie。这样，所有子系统都能读取这个Cookie，判断你已经登录。

代码示例：

  • 服务端：登录时创建Session，设置Cookie，标记用户身份。
  • 客户端：每次请求都检查是否有SSO Session Cookie，如果没有跳转登录，验证后创建本地Session。
// 服务器端创建Session并设置Cookie，Cookie域名为 .example.com，实现跨子域共享
Cookie cookie = new Cookie("SSO_SESSION_ID", session.getId());
cookie.setDomain(".example.com");
cookie.setHttpOnly(true);
cookie.setSecure(true);
response.addCookie(cookie);

优缺点：

  • 优点
  • 简单易实现，符合传统Web开发习惯
  • 服务端可控，会话失效能即时生效
  • 缺点
  • 只能同一顶级域名下用（子域共享Cookie）
  • Cookie受限于浏览器，移动端支持有限
  • 有一定CSRF风险，需要额外防护




-02-

基于 JWT 的无状态现代SSO 

原理：

JWT（JSON Web Token）就像是一张“数字通行证”，上面写满了你的身份信息和签名。认证服务器发给你这个通行证，你去哪个系统都能凭它证明身份，无需每次都去服务端查状态。

代码示例：

  • 登录后，认证服务生成签名过的JWT，包含用户ID、角色等信息。
  • 各客户端接收JWT，后续请求都带着它，后端通过验证签名确认用户身份。
  • 不需要服务端保存会话状态，完全无状态。

服务端登录生成JWT：

String jwt = jwtUtil.generateToken(user);
String jwt = jwtUtil.generateToken(user);

客户端携带JWT访问各系统：

axios.defaults.headers.common['Authorization'] = `Bearer ${token}`;
axios.defaults.headers.common['Authorization'] = `Bearer ${token}`;

优缺点：

  • 优点
  • 跨域无障碍，特别适合微服务架构和前后端分离
  • 不依赖Cookie，减少CSRF攻击风险
  • 支持各种客户端：Web、移动APP、API调用
  • 缺点
  • 令牌无法即时撤销（除非加黑名单）
  • JWT体积相对较大，网络传输成本增加
  • 需要在客户端做好令牌安全管理和刷新机制




-03-

企业级OAuth 2.0 + OpenID Connect

原理：

OAuth 2.0 是授权框架，OpenID Connect（OIDC）是在OAuth基础上的认证层。它就像银行的“统一身份认证中心”，支持复杂的授权流程和第三方接入，安全性和灵活性都很高。

代码示例：

  • 搭建授权服务器，支持多种授权模式（密码模式、授权码模式、刷新令牌等）。
  • 资源服务器负责保护各业务接口。
  • 客户端通过标准协议进行认证授权，拿到访问令牌后访问资源。

授权服务器配置：

@EnableAuthorizationServer
public class AuthorizationServerConfig extends AuthorizationServerConfigurerAdapter {// 配置客户端、令牌生成与增强
}

客户端配置：

spring:security:oauth2:client:registration:custom:client-id: web-clientclient-secret: secretauthorization-grant-type: authorization_coderedirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"

优缺点：

  • 优点
  • 最成熟的行业标准，安全性高
  • 令牌撤销机制完善，支持多租户和多客户端
  • 认证与授权职责明确，扩展性极强
  • 缺点
  • 实现复杂，学习成本高
  • 小型项目可能“杀鸡用牛刀”




-04-基于 Spring Session 的分布式 SSO

原理：

Spring Session 就像一个大家共用的会话仓库，把会话数据放到Redis等共享存储。不同应用访问时，都从同一个地方读取用户会话，实现统一登录状态。

代码示例：

  • 引入Spring Session + Redis依赖
  • 配置统一的Session存储和Cookie策略
  • 各应用配置统一认证过滤器，验证共享Session
@EnableRedisHttpSession
public class SessionConfig {@Beanpublic LettuceConnectionFactory connectionFactory() {return new LettuceConnectionFactory(redisConfig);}
}

优缺点：

  • 优点
  • 与Spring生态无缝集成，开发简单
  • 共享Session支持复杂会话信息
  • 缺点
  • 依赖Redis等中央存储
  • Cookie机制仍需依赖，限制非Web应用场景






-05-  如何选？

Cookie-Session

同域名小型应用，简单需求

跨域、多端、移动App

JWT

分布式微服务，跨域，移动端

需要即时令牌撤销的高安全场景

OAuth 2.0/OIDC

企业级、多租户，第三方集成

小型快速开发，资源受限

Spring Session

Spring生态，中型企业应用

异构技术栈，非Web应用

总结：

单点登录的世界里，没有万能钥匙，只有最适合的那把。

  • 想快速落地、简单管理，同域Cookie-Session就够用。
  • 追求分布式、跨端无状态，JWT轻装上阵。
  • 需要企业级安全保障和第三方扩展，OAuth2.0/OIDC是首选。
  • 使用Spring生态的企业，中型应用可优先考虑Spring Session方案。


选对方案，不仅提升用户体验，更能保证系统安全与维护便利。

希望本文能帮你少走弯路，打造稳定、高效的SSO体系！


热门文章

一套能保命的高并发实战指南

架构师必备：用 AI 快速生成架构图


-05-粉丝福利

我这里创建一个程序员成长&副业交流群，


和一群志同道合的小伙伴，一起聚焦自身发展，

可以聊：

技术成长与职业规划，分享路线图、面试经验和效率工具，


探讨多种副业变现路径，从写作课程到私活接单，


主题活动、打卡挑战和项目组队，让志同道合的伙伴互帮互助、共同进步。


如果你对这个特别的群，感兴趣的，

可以加一下，微信通过后会拉你入群，
但是任何人在群里打任何广告，都会被我T掉。