单点登录（SSO）主流方案对比
CAS（Central Authentication Service）协议
工作原理：
基于票据机制（TGT和ST），用户首次登录后获得TGT（票据授权票），后续访问应用时通过TGT换取ST（服务票）完成认证
技术特点：
集中式认证：CAS Server作为独立认证中心，统一管理用户凭证16。
安全性高：支持HTTPS、票据加密和短期有效性控制16。
扩展性：支持自定义属性（如用户角色）返回，适用于企业级RBAC权限管理68。
适用场景：
企业内部系统集成（如OA、ERP等）16。
教育、政府等需高安全性和集中管理的场景8。OAuth 2.0 / OpenID Connect
工作原理：
OAuth 2.0：授权框架，通过令牌（Access Token）授权第三方应用访问资源，非严格SSO，但可通过组合实现27。
OpenID Connect：基于OAuth 2.0的身份层，提供ID Token标准化用户信息27。
技术特点：
标准化协议：支持多种授权模式（如授权码、隐式模式）2。
跨平台：适用于Web、移动端和第三方应用集成7。
轻量级：依赖JSON Web Token（JWT）实现无状态认证27。
适用场景：
面向公众的互联网应用（如社交登录）27。
需第三方应用授权的场景（如API资源访问）7。SAML（Security Assertion Markup Language）
工作原理：
基于XML的协议，通过身份提供者（IdP）生成包含用户信息的SAML断言，传递给服务提供者（SP）完成认证27。
技术特点：
强安全性：支持XML签名和加密，适用于企业级安全需求2。
联邦身份：支持跨组织的身份联合（如B2B协作）2。
复杂性高：需处理XML解析和复杂配置2。
适用场景：
企业间协作（如供应链系统）2。
需联邦身份管理的跨国机构7。基于Cookie的SSO（同域/跨域）
工作原理：
同域SSO：共享顶级域名（如.example.com），通过Cookie在子域间传递登录状态27。
跨域SSO：依赖中央认证服务生成令牌，通过重定向和Token验证实现跨域认证27。
技术特点：
简单易用：适用于同域名下的多子系统27。
局限性：跨域需复杂处理（如Token中继或代理）7。
适用场景：
单一域名的多模块系统（如电商平台的订单、用户中心）27。Token-Based SSO（如JWT）
工作原理：
用户登录后生成自包含的Token（如JWT），存储于客户端，应用通过验证Token签名和有效期实现认证27。
技术特点：
无状态：Token自包含用户信息，无需服务端存储会话27。
灵活性强：支持跨域和微服务架构7。
安全性依赖：需防范XSS攻击和Token泄露7。
适用场景：
分布式微服务架构7。
单点登录方案需根据安全性需求、技术架构和应用场景综合选择：
企业内网：优先CAS协议，支持高安全性和集中管理16。
互联网应用：推荐OAuth/OpenID Connect，适配多平台和开放生态27。
跨域/联邦身份：SAML协议更适用于复杂企业协作
下面重点介绍CAS方案：
TGT和ST的定义及区别
TGT：Ticket Granting Ticket（票据授予票据），是用户在CAS Server成功登录后生成的核心票据，用于后续签发其他服务票据
ST：Service Ticket（服务票据），是CAS Server通过TGT为用户签发的，可以根据ST验证返回用户信息
ST一般在url中携带，比如：http://webapp.example.com/resource?ticket=ST-123456
TGT则是写入CAS Server域名的cookie中
用户 -> Web1
| |
| V
| 用户访问https://a.example.com/resource，应用A的CAS客户端过滤器拦截请求，检测无本地会话Cookie或token
| |
| V
| 返回302 https://cas.example.com/login?service=https://a.example.com/cas-callback 重定向到CAS Server
| |
| V
| CAS Server无ST参数
| |
| V
| 重定向到Login页面
| |
| 用户输入账号密码后，CAS Server验证身份，生成TGT（Ticket Granting Ticket）存储于服务端，并在浏览器写入TGC（
Ticket Granting Cookie）（域为cas.example.com）
| |
| V
| CAS Server生成ST（Service Ticket），重定向至service参数指定的地址，携带ST作为URL参数
https://a.example.com/cas-callback?ticket=ST-123456
| |
| V
| Web1 CAS Client到server校验ST，返回用户信息
https://cas.example.com/serviceValidate?ticket=ST-123456&service=https://a.example.com/cas-callback
| |
| V
| 校验成功，重定向回web1 https://a.example.com/cas-callback
返回了用户信息，默认只有用户名，通过配置也可以返回用户角色
<cas:serviceResponse>
<cas:authenticationSuccess>
<cas:user>alice</cas:user>
</cas:authenticationSuccess>
</cas:serviceResponse>
| |
| V
应用A根据返回的用户信息生成web1的会话（比如token或cookie）
重定向至原始请求资源：将用户重定向到初始访问的受保护页面（如https://a.example.com/resource
| |
| V
| 用户首次访问Web1完成
| |
|
| V
| 用户访问https://b.another.com/data，应用B的CAS客户端过滤器检测无本地会话，触发重定向
| |
| V
| 302 https://cas.example.com/login?service=https://b.another.com/cas-callback 重定向到CAS Server
浏览器自动携带TGC
| |
| V
| CAS Server从Cookie（对应cas server的域名）读TGT
| |
| V
| 生成随机ST返回Web2，https://b.another.com/cas-callback?ticket=ST-789012
| |
| V
| Web2 CAS Client到cas server校验ST，返回用户信息
| |
| V
| 校验成功，保存用户信息，生成web2的会话
| |
| V
| 用户首次访问Web2完成
| |
| V
| 用户后续访问Web1/Web2
| |
| V
| 根据token或cookie验证会话，无需到SSO server
