企业里做单点登录SSO技术选型环节最容易卡住SAML 2.0、OAuth 2.0、OIDC、CAS、JWT——名字都听过但到底该用哪个用友 ERP 怎么接泛微 OA 怎么接那个厂商已经不存在的老系统怎么接这篇文章把协议选型讲清楚再按能改造 / 半改造 / 不能改造三类系统给出具体接入方案。内容基于安当 ASP 统一身份认证平台的实施经验。一、SSO 的本质把认证从应用里抽出来先建立一个基本认知。传统模式下每个应用自己干三件事存用户表、校验密码、维护会话。SSO 做的事就是把前两件抽到统一的认证中心应用只保留最后一件。抽出来之后的通用流程不管什么协议骨架都一样1. 用户访问应用 A应用发现未登录 2. 应用把用户重定向到认证中心携带自己的身份标识和回调地址 3. 认证中心检查这个浏览器有全局会话吗 - 没有 → 展示登录页用户认证可叠加 MFA - 有 → 跳过登录直接放行 4. 认证中心颁发一张凭证票据/授权码/断言给应用 A 5. 应用 A 拿凭证向认证中心换取用户身份信息建立本地会话 6. 用户再访问应用 B → 第 3 步命中全局会话 → 无感登录安当 ASP 的 SSO 原理就是这套基于票据Ticket或令牌Token的机制用户首次认证通过后平台颁发加密令牌后续访问其他应用时由应用向平台校验令牌有效性实现无缝跳转。关键洞察SSO 的难点从来不是协议实现而是如何让 20 个不同年代、不同架构的系统都愿意接受同一个身份来源。二、四种协议对比什么场景用什么维度SAML 2.0OAuth 2.0OIDCCAS本质身份联合认证授权框架不是认证OAuth 2.0 之上的认证层校园/企业经典 SSO 协议数据格式XML 断言JSON Bearer TokenJSON JWTid_tokenXML票据校验传输方式浏览器 POST/Redirect BindingHTTP 重定向 后端换取同 OAuth 2.0HTTP 重定向 后端校验移动端友好差XML 重、跳转多好好一般典型场景企业级 Web 应用、政务系统、传统 SaaS第三方应用授权访问 API现代 Web/APP/小程序登录高校、老牌企业内网系统复杂度高签名、加密、元数据中中低是否携带用户身份是断言含属性否只有访问令牌是id_token 含 claims是校验返回用户属性选型口诀新系统、移动端、前后端分离→ 首选OIDC授权码模式 PKCE传统企业 Web 应用、政务系统、采购的商业 SaaS→SAML 2.0很多商业软件只支持这个只需要授权 API 访问不需要知道用户是谁→OAuth 2.0存量系统已经在用 CAS→ 保留 CAS别为了统一而重构服务端到服务端调用→ OAuth 2.0 的Client Credentials 模式有个常见误区要澄清OAuth 2.0 不是认证协议。它解决的是允许应用 X 访问我在平台上的资源而不是我是谁。拿 OAuth 2.0 直接当登录用俗称用授权当认证会有安全隐患正确做法是用它的超集 OIDC——多了一个id_token里面是签名过的用户身份断言。ASP 平台对这几种协议都做了支持OAuth 2.0、OpenID Connect 1.0、SAML 2.0、LDAP、JWT加上 RADIUS 覆盖网络层一共 20 标准协议。三、OIDC 接入实战一个标准 Web 应用的完整流程以授权码模式为例这是最推荐的方式不在浏览器暴露令牌。第一步在 ASP 创建应用拿到client_id和client_secret配置回调地址。第二步应用侧发起认证GET https://asp.company.com/oauth2/authorize ?client_idoa-system response_typecode scopeopenid profile email redirect_urihttps://oa.company.com/sso/callback statea1b2c3d4 # 防 CSRF必须校验 noncen0nce123 # 防重放id_token 里会带回第三步用户认证完成ASP 回调GET https://oa.company.com/sso/callback?codeSplxlOBeZQstatea1b2c3d4第四步后端用 code 换 tokenPOST https://asp.company.com/oauth2/token Content-Type: application/x-www-form-urlencoded Authorization: Basic base64(client_id:client_secret) grant_typeauthorization_code codeSplxlOBeZQ redirect_urihttps://oa.company.com/sso/callback返回{access_token:eyJhbGciOiJSUzI1NiIs...,token_type:Bearer,expires_in:3600,refresh_token:tGzv3JOkF0XG5Qx2TlKWIA,id_token:eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...}第五步校验 id_token这一步千万别省id_token是一个 JWT解开后大致长这样{iss:https://asp.company.com,sub:u-10024,aud:oa-system,exp:1785312000,iat:1785308400,nonce:n0nce123,name:张三,preferred_username:zhangsan,email:zhangsancompany.com,dept:信息中心,amr:[pwd,otp]}必须校验的项签名用 ASP 的 JWKS 公钥验签别信alg: noneiss签发者是不是预期的认证中心aud受众是不是自己的 client_idexp是否过期nonce是否与发起时一致校验通过后用sub作为用户唯一标识建立本地会话。注意用sub而不是用户名或邮箱做主键——用户名会改邮箱会换sub不变。amr字段Authentication Methods References很有用它告诉应用这次登录用了哪些认证方式。敏感操作可以检查是否包含otp不包含就要求重新做强认证step-up authentication。ASP 还提供前端 JavaScript SDK支持 Vue/React 等主流框架前后端分离项目可以直接用省掉手写协议交互的工作。四、三类业务系统的接入策略真实企业里能按标准协议对接的系统通常不到一半。ASP 把应用接入分成三种类型对应三类现实类型一自建应用能改造管理员在 ASP 手动创建应用配置应用名称、Client ID、回调地址、认证协议SAML/OIDC 等然后由开发团队按协议改造登录逻辑。适用自研系统、有源码有团队的系统。改造量一般 1-2 人日。分两种细分场景有用户源应用授权码模式应用本地保留用户表SSO 只负责认证登录后按sub或用户名匹配本地用户无用户源应用隐藏式模式应用不维护用户表用户信息完全由 ASP 下发类型二第三方应用模板一键接入ASP 内置了预置应用市场主流 SaaS 和开源系统金蝶云星空、GitLab、石墨文档等提供现成模板无需开发填几个参数就完成 SSO 配置。适用采购的商业软件、常见开源系统。典型对接周期1 天。类型三自动登录应用表单代填零改造这是解决老系统接不进来的杀手锏。原理在用户端安装轻量级浏览器插件或客户端代理当用户访问目标系统登录页时代理拦截请求向 ASP 申请解密后的凭据模拟输入完成登录。关键特性全程用户不可见真实密码——凭据在插件内解密后直接填入表单平台可定期轮换目标系统密码用户完全无感每次代填绑定真实操作人身份解决共享账号追溯问题适用厂商跑路的老 ERP、闭源 C/S 系统、多人共用的电商后台、外部供应商门户。一个真实案例某知名电商公司运营多个平台店铺后台系统只有少量共享账号运营、客服、仓管多岗位共用密码记在 Excel 和聊天工具里。部署 ASP SYP 密码保险箱后密码集中托管、后台自动代填、明文对使用者完全不可见每次登录绑定真实操作人。效果100% 明文密码隔离人均登录效率提升 30%离职即时撤权无需改共享密码。五、几个必须提前想清楚的设计问题1. 单点登出SLO怎么做用户在 ASP 退出后其他应用的本地会话怎么办三种做法方案机制优缺点前端通道登出认证中心页面嵌入各应用的登出 iframe简单但受第三方 Cookie 限制可靠性下降后端通道登出认证中心向各应用推送登出通知可靠但应用要实现接收端点短会话 令牌校验应用本地会话设短靠令牌续期时发现已登出最简单代价是有窗口期实践建议对安全要求高的应用用后端通道登出一般应用用短会话 令牌校验就够。2. 会话有效期怎么配三层会话要分别设定认证中心全局会话8 小时一个工作日应用本地会话30 分钟-2 小时access_token1 小时refresh_token8 小时原则越靠近敏感资源的会话越短。财务、人事系统的本地会话建议 15-30 分钟。3. 用户属性怎么映射ASP 下发的字段和应用本地字段名往往对不上。ASP 支持应用账号自定义映射在平台侧配置映射规则避免改造应用。4. 首次登录用户怎么处理用户在 ASP 有身份但应用本地还没记录两种策略JIT Provisioning即时开通首次 SSO 登录时按断言里的属性自动建本地用户预同步通过 API 或 LDAP 提前把用户批量灌进应用大部分场景推荐 JIT减少同步链路。六、常见问题QSSO 上线后认证中心挂了是不是全公司都进不去这是必须回答的风险。对策双机热备 集群部署Keepalived VIP 漂移、PostgreSQL 主从复制RTO 30 秒、RPO ≈ 0关键应用保留本地应急登录入口只给少数管理员并强审计。QSAML 断言签名一直校验失败怎么排查按顺序查① IdP 元数据里的证书和实际签名证书是否一致② 断言是整体签名还是 Response 签名SP 侧配置要匹配③ 时钟偏差SAML 对 NotBefore/NotOnOrAfter 敏感NTP 必须同步④ XML 规范化方式c14n是否一致。Q能不能既做 SSO 又保留原来的账号密码登录技术上可以双入口但强烈建议过渡期后关闭本地登录入口。否则 SSO 的审计和权限回收能力形同虚设——离职员工照样能走本地入口进去。QJWT 用对称密钥HS256还是非对称RS256多应用场景一律用RS256。HS256 需要把密钥分发给每个应用任何一个应用泄露密钥攻击者就能伪造所有应用的令牌。RS256 只分发公钥安全边界清晰。QSSO 会降低安全性吗“一把钥匙开所有门”会集中风险所以必须配套两件事① 认证中心强制 MFA密码 OTP/UKey/FIDO2② 敏感应用做 step-up 认证进入时要求重新做强认证。做到这两点SSO 的整体安全性远高于每个系统各自弱口令的状态。写在最后SSO 项目的成败技术占三成节奏占七成。我的建议是先接 5 个用户量最大、改造最容易的系统通常是 OA、门户、邮箱、报销、考勤让全员在两周内感受到少记 5 个密码的好处。有了群众基础再去啃 ERP、去啃那个厂商已经不在了的老系统。协议选型反而是最简单的部分新系统 OIDC商业软件 SAML老系统表单代填。三条路径覆盖 95% 的情况。本文技术内容参考《安当 ASP 身份认证服务平台技术白皮书 V4.0》。ASP 支持 OAuth 2.0 / OIDC / SAML 2.0 / LDAP / JWT 等 20 标准协议提供预置应用市场与免改造表单代填能力。