单点登录核心目标：一次登录，多信任系统免登，分为「同源简单 SSO」、「跨域标准协议 SSO」、「企业内部自研轻量化方案」、「现代云原生 / 分布式 SSO」几大类，下面按工业界使用热度排序，讲清原理、适用场景、优缺点。
一、标准协议类（生产最主流，推荐优先选）
1. OAuth2.0 + OIDC（OpenID Connect）⭐⭐⭐⭐⭐
当前互联网、SaaS、云平台首选，微信 / 支付宝 / GitHub 登录、企业 IdP 基本都是这套
OAuth2.0：授权协议，本身不是认证协议，解决 “给第三方应用授权访问资源”
OIDC 1.0：在 OAuth2 之上扩展，增加
id_token(JWT)，变成认证协议，真正实现 SSO角色：IdP（身份提供商，如 Authelia、Keycloak、Azure AD、钉钉、企业微信）、RP/Client（业务应用）
流程：授权码模式（Authorization Code）最常用；还有 PKCE 模式给 SPA、移动端
特点： ✅ 标准化、跨语言、跨厂商、支持联邦身份；支持登出（Front/Back-channel logout） ✅ Token 自包含（JWT），应用本地校验，不用每次回 IdP 查库 ❌ JWT 无法撤销（除非搭配黑名单 /introspect 接口）；需要做好密钥管理
典型产品：Keycloak、Authelia、Casdoor、Okta、Auth0、企业微信 / 钉钉 OIDC
2. SAML 2.0（Security Assertion Markup Language）⭐⭐⭐⭐
传统政企、金融、老 OA、国外企业 IdP 大量使用，偏笨重但是企业联邦标准
基于 XML 断言，HTTP-Redirect / HTTP-POST 绑定
典型场景：政务系统、外企 ADFS、Salesforce、老 ERP、校园统一身份认证
特点： ✅ 成熟稳定、强安全、支持复杂权限断言、企业间身份联邦 ❌ XML 报文繁琐、调试难、不适合移动端、SPA；现代新项目很少从零实现 SAML
3. CAS（Central Authentication Service）⭐⭐⭐
老牌开源 SSO 协议，国内高校、传统政务系统用得很多（CAS Server）
核心模型：中央认证服务，Ticket 机制（TGT、ST）
流程：登录 CAS 中心 → 下发 TGT Cookie；业务系统跳转 CAS 拿 ST，校验 ST 拿到用户信息
特点： ✅ 轻量易懂，源码成熟（Apereo CAS），早期国内 SSO 标杆 ❌ 协议老旧，生态不如 OIDC；原生对移动端、前后端分离支持弱；逐步被 OIDC 替代
二、Cookie 共享类（简单自研方案，仅限同主域）
适合同一根域名下多子系统，跨一级域名不能用
1. 共享 Cookie + 统一 Session 中心
原理： 登录中心在 .shturl. 种下顶级域 Cookie；所有子应用 a.shturl.、b.shturl. 都能读取这个 Cookie；统一 Session 存在 Redis。
优点：最简单，开发成本低
缺点： ❌ 不能跨一级域名（浏览器同源策略限制） ❌ CSRF 风险高；移动端、第三方外部应用无法接入
适用：内部后台一套主域下多个子系统，不对外 SaaS 接入
2. 父页面跨域 PostMessage + 登录中心 iframe（跨域简易方案）
原理： 各业务页面内嵌登录中心 iframe，iframe 和登录中心同域，能读到登录 Cookie；业务页面通过 postMessage 向 iframe 查询登录态。
优点：绕过跨域拿登录态
缺点：安全坑多、容易被 XSS 劫持；弹窗拦截；现代架构尽量避免
三、Token 中转 / 票据类自研方案（跨域自研 SSO）
1. 跳转票据模式（简易 CAS 思想）
流程：
访问业务系统，未登录 → 重定向到统一登录中心
用户登录成功 → 生成一次性临时票据 ticket，跳转回业务系统
业务系统拿着 ticket 请求登录中心校验接口，拿到用户信息、建立本地会话
登录中心保留全局登录会话
优点：可跨域，逻辑简单，很多中小公司早期自研 SSO 都是这套
缺点：需要自己实现登出同步、防重放、票据过期；轮子多，容易写出安全漏洞
很多自研 SSO 本质就是复刻 CAS 思想，只是协议不标准
四、基于代理网关的 SSO（云原生、K8s 生态热门）
反向代理 SSO / 认证网关（Auth Proxy）⭐⭐⭐⭐
代表：OAuth2 Proxy、Authelia、Pomerium、Ingress-Nginx + auth-url 架构：网关统一拦截所有应用请求，网关去 IdP（OIDC/SAML）做认证；认证通过后，把用户信息通过请求头传给后端业务服务。
业务应用不需要改代码，不用对接 SSO SDK，只需要读取 Header
适合：K8s 集群内部一堆内部服务、监控面板（Grafana、Prometheus）、内部工具
局限：粒度粗，适合全局认证；复杂业务权限还需要应用自己处理
五、其他身份相关补充方案
AD / LDAP + Kerberos Windows 域环境传统方案，企业内网 Windows 机器免登（域登录）；现在一般是 IdP 对接 LDAP，对外走 OIDC/SAML，很少直接 Kerberos 给 Web SSO。
JWT 单点登录（注意：JWT 不是 SSO 协议！） 很多人混淆：JWT 只是令牌格式。可以配合 OIDC、自研票据方案使用；单独 JWT 无法天然实现 SSO，没有统一登录页面、没有全局登出能力。
WebAuthn / Passkey 是认证方式（无密码登录），不是 SSO 协议，常和 OIDC 结合，作为 IdP 里面的登录方式。
方案选型速查表
工程上选型建议
新项目、对外 SaaS、多端（Web/App/ 小程序）：优先 OIDC，直接上成熟 IdP：Keycloak（开源自托管）、Casdoor、Authelia
对接老政企、ADFS、国外系统：SAML2.0
K8s 内部一堆中间件、内部工具：OAuth2 Proxy / Authelia 网关 SSO
同根域名下几个后台内部系统，预算有限：共享 Cookie+Redis Session
❌ 尽量不要从零手写一套自研 SSO，登出同步、票据防重放、安全漏洞非常容易踩坑
补充两个高频概念区分
SSO：解决一次登录多个系统
SSO ≠ 统一身份管理（IAM）：IAM 包含账号、权限、组织、MFA，SSO 是 IAM 其中一个能力；Keycloak、Casdoor 本质是 IAM，对外暴露 OIDC/SAML 能力做 SSO
单点登出（SLO）是 SSO 难点：OIDC 支持前后端通道登出；自研方案很容易出现 “登录中心退出了，业务系统还保持登录”
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢