SSO单点登录实现方案
1. 什么是 SSO
SSO，全称是 Single Sign-On，中文叫 单点登录。
它解决的问题是：
用户只需要登录一次，就可以访问多个相互信任的系统。
比如公司内部有这些系统：
OA 系统
CRM 系统
财务系统
工单系统
数据看板系统
如果没有 SSO，用户访问每个系统都要登录一次，体验很差，账号密码也不好统一管理。
有了 SSO 之后，用户只需要在统一登录中心登录一次，后续访问其他系统时，就可以自动识别登录状态。
2. SSO 的核心思想
SSO 的核心不是“所有系统共用一个 Session”，而是：
所有业务系统都信任同一个认证中心。
这个认证中心一般叫：
SSO Server
统一认证中心
Identity Provider，简称 IdP
登录中心
业务系统一般叫：
Client
Service Provider，简称 SP
Resource Server
业务应用
简单来说：
用户登录状态由认证中心统一管理
业务系统不直接处理用户名密码
业务系统只校验认证中心签发的登录凭证
3. 普通登录和 SSO 登录的区别
普通登录流程：
用户 -> 系统A -> 输入账号密码 -> 系统A保存登录态
用户 -> 系统B -> 输入账号密码 -> 系统B保存登录态
用户 -> 系统C -> 输入账号密码 -> 系统C保存登录态
SSO 登录流程：
用户 -> 系统A -> 跳转统一登录中心 -> 登录成功
用户 -> 系统B -> 跳转统一登录中心 -> 已登录，直接返回
用户 -> 系统C -> 跳转统一登录中心 -> 已登录，直接返回
区别在于：
4. SSO 的基本架构
一个典型的 SSO 架构如下：
这里有三个关键角色：
5. SSO 的常见实现方案
SSO 有多种实现方式，不同场景适合不同方案。
常见方案有：
同主域 Cookie 共享方案
Token 认证方案
CAS 协议方案
OAuth2 / OpenID Connect 方案
SAML 方案
下面分别说明。
一、同主域 Cookie 共享方案
1. 适用场景
如果多个系统属于同一个主域名，可以通过 Cookie 共享实现简单 SSO。
例如：oa.example.com crm.example.com pay.example.com它们都属于：example.com ，那么登录系统可以把 Cookie 设置到主域：.example.com ，这样多个子系统都能读取这个 Cookie。
2. 登录流程
3. 优点
实现简单
性能好
适合同一个公司内部系统
不需要复杂协议
4. 缺点
只适合同主域名
跨顶级域名不好处理
Cookie 泄露风险较高
不适合开放平台和第三方系统
例如下面这种就不好直接共享 Cookie：
system-a.com
system-b.net
system-c.org
二、Token 认证方案
1. 基本思想
用户登录成功后，认证中心生成一个 Token。
业务系统拿到 Token 后，通过以下方式确认用户身份：
本地校验 Token
调用认证中心校验 Token
使用公钥验证 JWT 签名
Token 中一般会包含：
{
"userId": "10001",
"username": "zhangsan",
"roles": ["admin"],
"expireTime": 1710000000
}
2. 登录流程
3. Token 可以放在哪里
常见存放位置有：
Web 系统一般更推荐：
HttpOnly + Secure + SameSite Cookie
这样可以减少 XSS 窃取 Token 的风险。
4. JWT 和普通 Token 的区别
Token 可以分为两类：
JWT 的优点是业务系统可以本地校验，不一定每次都请求认证中心。
但是 JWT 也有问题：
一旦签发，在过期前不容易主动失效
Token 太长会增加传输成本
权限变更后，旧 Token 可能还有效
不适合放太敏感的信息
所以实际项目中经常会这样设计：
短期 Access Token + 长期 Refresh Token
三、CAS 协议方案
1. CAS 是什么
CAS，全称是 Central Authentication Service，是一个经典的单点登录协议。
它的核心思想是：
认证中心负责登录，业务系统通过票据确认用户身份。
CAS 里面有几个重要概念：
2. CAS 登录流程
3. CAS 的特点
优点：
协议成熟
适合传统 Web 系统
对后端应用友好
支持单点登录和单点退出
缺点：
对前后端分离、移动端支持没有 OAuth2 / OIDC 自然
生态相对偏传统
接入第三方开放平台时不如 OAuth2 通用
四、OAuth2 / OpenID Connect 方案
1. OAuth2 和 OIDC 的关系
很多人会把 OAuth2 当成登录协议，其实严格来说：
OAuth2 主要解决授权问题
OIDC 在 OAuth2 基础上解决认证登录问题
也就是说：
如果要做标准化 SSO，更推荐使用：
OAuth2 + OpenID Connect
2. OIDC 里的核心 Token
OIDC 常见 Token 有三个：
其中最关键的是：
ID Token 用来证明用户是谁
Access Token 用来访问接口资源
3. 标准授权码流程
4. 为什么推荐授权码模式
在 Web 系统中，尤其是后端参与登录流程的系统，推荐使用：
Authorization Code Flow
原因是：
Token 不直接暴露在浏览器地址栏
可以通过后端安全保存 Client Secret
适合传统 Web 和前后端分离架构
是目前主流 SSO 实现方式
如果是纯前端 SPA 应用，则通常使用：
Authorization Code Flow + PKCE
PKCE 可以防止授权码被截获后滥用。
5. OIDC 方案的优点
标准化程度高
生态成熟
支持 Web、App、小程序、第三方平台
可以和企业身份系统集成
适合微服务、前后端分离和开放平台
常见产品包括：
Keycloak
Authing
Okta
Auth0
Azure AD
Spring Authorization Server
五、SAML 方案
1. SAML 是什么
SAML，全称是 Security Assertion Markup Language。
它也是一种单点登录协议，常见于企业级系统，尤其是国外 SaaS 和传统企业软件。
SAML 里面有两个核心角色：
2. SAML 的特点
优点：
企业级系统支持广泛
适合和传统 IAM 系统集成
很多海外 SaaS 支持 SAML 登录
缺点：
XML 格式较重
对现代前后端分离应用不如 OIDC 轻便
实现和调试复杂度较高
如果是新系统，一般优先考虑 OIDC。
如果要接入老牌企业系统或国外 SaaS，SAML 仍然很常见。
六、不同方案如何选择
可以简单按场景选择：
如果是新项目，比较推荐：
OAuth2 + OpenID Connect
这是目前兼容性、扩展性和标准化程度都比较好的方案。
七、一个推荐的 SSO 落地架构
对于企业内部系统，可以设计成下面这样：
核心组件包括：
1. 登录流程设计
推荐流程：
.svg)
2. Token 设计
推荐使用：
Access Token + Refresh Token
Access Token：
有效期短，比如 15 分钟到 2 小时
用于访问接口
Refresh Token：
有效期长，比如 7 天到 30 天
用于刷新 Access Token
需要服务端存储和可撤销
这样既能提升安全性，也能保证用户体验。
3. 登录态设计
认证中心维护全局登录态：
SSO Session
业务系统可以维护自己的本地登录态：
Local Session
这样做的好处是：
认证中心负责统一登录
业务系统不需要频繁请求认证中心
每个系统可以有自己的会话控制
单点退出时可以统一通知业务系统
八、单点退出如何实现
SSO 不仅要解决“单点登录”，还要考虑“单点退出”。
否则会出现：
用户从系统 A 退出了
但是系统 B 仍然是登录状态
单点退出常见方式有三种。
1. 前端跳转退出
认证中心退出后，依次跳转各个业务系统的退出地址。
优点：
简单
容易理解
缺点：
依赖浏览器跳转
某个系统失败可能影响后续退出
用户体验一般
2. 后端通知退出
认证中心退出后，服务端调用各个业务系统的退出接口。
SSO Server -> System A logout
SSO Server -> System B logout
SSO Server -> System C logout
优点：
可靠性更好
用户无感知
适合企业内部系统
缺点：
业务系统需要提供退出接口
需要处理接口失败和重试
退出接口要保证安全性
3. Token 黑名单
如果使用 JWT，可以在退出时把 Token 加入黑名单。
业务系统校验 Token 时，同时检查黑名单。
优点：
可以让 JWT 提前失效
适合分布式系统
缺点：
需要额外存储
每次校验可能要访问 Redis
黑名单需要设置过期时间
九、SSO 实现中的安全问题
SSO 是登录入口，一旦出问题，影响所有系统，所以安全设计非常重要。
1. 防止 Token 泄露
建议：
Access Token 有效期要短
敏感 Token 不要放在 URL 中
Web 场景优先使用 HttpOnly Cookie
开启 HTTPS
2. 防止 CSRF
如果使用 Cookie 维护登录态，需要考虑 CSRF。
常见措施：
SameSite Cookie
CSRF Token
验证 Origin / Referer
重要操作二次确认
3. 防止 XSS
如果 Token 存在 LocalStorage，一旦页面出现 XSS，Token 可能被直接读取。
所以要注意：
避免直接拼接 HTML
对用户输入做转义
设置 CSP
Token 尽量放 HttpOnly Cookie
4. 防止重放攻击
授权码、票据、临时 Token 要满足：
一次性使用
短时间有效
使用后立即失效
比如 CAS 的 ST，OIDC 的 Authorization Code，都应该是短期一次性凭证。
5. Redirect URI 白名单
SSO 登录经常涉及跳转，例如：
https://sso.example.com/login?redirect_uri=https://oa.example.com/callback
认证中心必须校验 redirect_uri 是否在白名单中。
否则可能出现开放重定向漏洞，攻击者可以诱导用户登录后跳转到恶意网站。
十、实际开发中的接口设计
可以设计这些核心接口：
如果是 OIDC 标准实现，还会有：
/.well-known/openid-configuration
这个接口用于暴露认证中心的配置信息。
十一、数据库表设计参考
一个简单的 SSO 系统，可以有这些表：
其中 client_app 表一般保存：
十二、SSO 和权限系统的关系
SSO 主要解决的是：你是谁。
权限系统主要解决的是：你能做什么。
两者不能混为一谈。
登录成功之后，系统只知道用户身份。至于用户能不能访问某个菜单、按钮、接口，还需要权限系统判断。
常见权限模型有：
企业系统中最常见的是：RBAC：用户 -> 角色 -> 权限
十三、总结
SSO 单点登录的本质是：
通过统一认证中心，让多个业务系统共享同一套身份认证能力。
常见实现方案中：
如果是新项目，推荐优先考虑：OAuth2 + OpenID Connect + Authorization Code + PKCE
如果是公司内部多个后台系统，也可以基于统一认证中心实现：SSO Server + Redis Session + JWT + 网关鉴权
最后要记住一点：
SSO 不只是“登录一次”，更重要的是统一身份、统一安全策略、统一账号生命周期管理。
真正成熟的 SSO 系统，不只是能登录，还要支持：
单点退出
Token 刷新
权限控制
多端登录管理
登录日志审计
账号禁用
密码策略
MFA 多因素认证
第三方应用接入
安全风控
这样才能支撑企业级系统的统一身份认证体系。
SSO单点登录实现方案
https://lautung.com/archives/w4i0o8Ie
评论