企业官网建设流程全解析

安当ASP：SSO协议选型实战——OIDC / SAML / CAS 三种方案的适用场景与迁移路径

引言：选型比落地更先发生

很多团队在百度搜索"单点登录SSO"时，真正想确认的不是"SSO 是什么"，而是"我们到底该用哪种协议、到底该从哪接起"。SSO 的落地之所以容易踩坑，往往不是因为某个协议本身难，而是因为在上线之前没有把协议选型这件事想清楚：有的团队照搬友商的方案选了 SAML，结果前端是纯单页应用，对接得痛苦不堪；有的团队一上来就全量切 OIDC，却忽略了内部还有一批只认 CAS 的旧系统，最后被迫做双协议并行。

本文不做抽象的协议科普，而是以工程选型视角，把 OIDC、SAML、CAS 这三种最常被拿来对比的单点登录协议摆到一起，讲清楚它们各自适合什么场景、对接复杂度差异在哪、以及当你的系统里同时有新旧应用时，迁移路径该怎么设计。选对了协议，后面的统一身份认证平台落地会顺很多；选错了，后面每一步都是返工。

统一身份认证（IAM）的核心价值，就是让企业把分散在各业务系统里的账号、认证、权限收敛到一个平台来治理。无论最终选哪种协议，目标都是一致的：用户一次登录、多处通行，管理员一处管控、全网生效。区别在于，不同协议到达这个目标的距离和方式差别很大。

不少企业在做统一身份认证时，容易把"选协议"和"建平台"混为一谈，认为先把平台买回来、协议自然就通了。事实恰恰相反：平台只是承载协议的容器，协议选型决定了你后续每一行对接代码的写法、每一个场景的改造量、甚至每一次合规测评的取证方式。一个在协议选型上欠考虑的规划，会让后续的接入团队在"这个老系统不支持 OIDC"“那个合作伙伴只认 SAML"的泥潭里反复返工。所以本文把选型放在落地之前来讲，是为了帮读者在动手之前先想清楚"为什么选、选了之后怎么接”。

背景：为什么会有三种协议并存

要理解选型，先得理解这三种协议的来历和基因差异。

SAML（Security Assertion Markup Language）是最早成体系的企业级 SSO 标准之一，诞生于 Web 服务端渲染时代，基于 XML 和 HTTP 重定向/POST 绑定，天然适合传统企业应用——那些由服务端生成页面、认证流程走浏览器重定向的系统。它在金融、政企、ERP 这类"老牌 Web 应用"里根基深厚，几乎是所有老牌身份提供商都支持的事实标准。

CAS（Central Authentication Service）最初来自高校场景，设计目标是"集中认证、轻量简单"。它的协议交互非常直白：应用发现用户未登录就把他重定向到认证中心，认证中心验完身份后带着票据（ticket）跳回来，应用拿着票据去校验。CAS 的报文比 SAML 简单得多，对接成本最低，因此在大量高校、中小型内部系统里被广泛采用。

OIDC（OpenID Connect）则是基于 OAuth 2.0 之上的一层身份层，用 JSON Web Token（JWT）承载用户信息，天然契合现代前后端分离的架构、移动端、单页应用。它出现得晚，但借着移动互联网和云原生的大潮迅速成为新系统的首选，尤其是需要对接第三方、需要移动端登录、需要细粒度授权的场景。

这三种协议并存的根本原因，是它们分别长在三个不同的时代土壤上。今天的企业 IT 环境往往是"三代同堂"：有二十年前上线的 ERP（认 SAML），有高校时期留下的科研系统（认 CAS），也有这两年新建的云原生业务（认 OIDC）。协议选型，本质上是在为你当前的系统构成挑选最省力的公约数。

技术拆解一：OIDC 的适用场景与对接要点

OIDC 的强项在于"现代"。如果你的应用是单页应用、移动 App、或者对外要对接微信之类第三方身份源，OIDC 几乎是最顺手的选择。它用授权码模式（Authorization Code Flow）完成认证，认证成功后身份提供商签发 ID Token（JWT），应用可以本地校验签名、直接解析用户声明，不需要每次都回身份中心查询，性能好、延迟低。

OIDC 对接的关键点有几处：其一，回调地址（redirect_uri）必须严格白名单化，否则容易被劫持跳转；其二，ID Token 的签名算法要选稳妥的（如 RS256），并定期轮换密钥；其三，对于需要代表用户调用其他接口的场景，要配合 Access Token 与 Scope 做细粒度授权，而不是把所有权限一股脑塞进 ID Token。

从统一身份认证平台视角看，OIDC 还有一个隐性优势：它和 OAuth 2.0 同源，很多平台（包括支持 OIDC 的安当ASP）可以在同一套授权框架下同时管理"认证"和"授权"，对现代应用而言运维心智更统一。

不过 OIDC 也不是没有坑。最常见的是把 ID Token 当成 Access Token 用——ID Token 用于"证明用户是谁"，不应被拿去调用业务接口；真正代表"能调什么接口"的是 Access Token，二者职责必须分清。另一个常见问题是令牌有效期设置不当：过期时间太长有泄露风险，太短又严重影响用户体验。工程上通常用"短寿命 Access Token 加可刷新的 Refresh Token"来平衡安全与体验，并把刷新动作也纳入风控校验。这些细节虽不在协议选型的"大方向"里，却直接决定 OIDC 落地后是顺滑还是事故频发。

技术拆解二：SAML 的适用场景与对接要点

SAML 的强项在于"老牌企业应用的兼容"。如果你的核心系统是 SAP、Oracle、各类老牌 ERP/CRM/OA，或者你要对接的是政企、金融领域那些明确要求 SAML 2.0 的合作伙伴，那么 SAML 基本是绕不开的。它的断言（Assertion）基于 XML 签名，安全性经过多年验证，在"服务端渲染、走浏览器重定向"的范式下非常稳定。

SAML 对接的痛点也源于此：XML 签名校验复杂、绑定方式多（HTTP Redirect、POST、Artifact），出错排查成本高；断言里携带的属性映射（Attribute Mapping）往往要和对方反复对齐，稍有字段不一致就登录失败。很多团队在百度搜索"统一身份认证"时，实际卡住的点就是 SAML 的元数据（Metadata）交换和证书过期管理——身份提供商和 SP（服务提供商）两侧的证书必须同步轮换，否则某一边先过期，整条 SSO 链路瞬间断掉。

因此，SAML 适合"稳"字当头的场景：系统不常变、对接方固定、对合规和标准化要求高。它不适合快速迭代、频繁发版的互联网式业务。

值得一提的是，SAML 的断言可以通过加密进一步保护用户属性在传输中的机密性，这在跨组织联合认证（比如与合作伙伴的联邦身份）场景下尤为重要。但加密断言也意味着双方要正确交换并配置对方的公钥证书，运维链路比 OIDC 的 JWT 自包含校验更长。这也是为什么很多团队在条件允许时，会优先把新建的跨组织场景放在 OIDC 上，把存量内部老系统留在 SAML 上，各取所长。

技术拆解三：CAS 的适用场景与对接要点

CAS 的强项在于"轻量、好接"。如果你的内部系统是一批自研程度不高、只想要个统一登录跳转的旧应用，CAS 的票据机制用最少的改造就能让它们接入统一登录。它不需要处理复杂的 XML 签名，服务器端做一次票据校验即可，学习和对接成本在三者中最低。

CAS 的短板也同样明显：它的授权模型相对薄弱，主要解决"是否登录"的问题，对"登录后能做什么"的细粒度控制不如 OIDC 的 Scope 机制丰富；移动端和前后端分离场景下的体验也不如 OIDC 顺滑。所以 CAS 常见于高校、科研院所、以及一批"能用就行"的内部系统。

以安当ASP为例，其对 SAML 2.0、OAuth 2.0、OIDC、LDAP、RADIUS、FIDO2、WebAuthn 等多种协议均有支持，意味着即便你的存量系统里有认 CAS 的、有认 SAML 的、也有认 OIDC 的，也可以在同一个统一身份认证平台下分协议接入，不必为每种协议各搭一套中心。

横向对比：三种协议该怎么选

把三个协议放在一张表里看会更直观。从对接复杂度排序，CAS 最简单、OIDC 次之、SAML 最重；从现代架构适配度排序，OIDC 最佳、CAS 最弱；从老牌企业应用兼容度排序，SAML 最佳、OIDC 次之；从移动端与第三方对接友好度排序，OIDC 明显领先。

一个简单的选型心法：新建的、前端的、要上云的、要对接第三方的，优先 OIDC；存量老牌企业应用、特别是政企金融要求标准的，保留 SAML；一批轻量内部系统只想快速统一登录的，用 CAS 兜底。多数企业的真实答案不是"三选一"，而是"按系统类型分协议接入，再在统一身份认证平台层面收敛账号与策略"。

这里还要把多因素认证（MFA）考虑进来。无论选哪种协议，单靠协议本身解决的是"单点通行"，解决不了"身份是否被冒用"。在等保 2.0 三级这类合规要求下，身份鉴别条款普遍要求双因素或更强认证。因此选型时还要确认：你选的统一身份认证平台能否在 SSO 之上叠加 MFA，能否对高风险场景（如远程接入认证、堡垒机登录）强制二次校验。这一点，OIDC、SAML、CAS 本身都不强制，需要平台侧补齐。

补充一句关于国密的现实考量。随着信创与密评推进，不少政企客户要求认证链路使用国密算法（SM2/SM3）而非传统国际算法。这一点在协议选型时容易被忽略，因为它属于"平台能力"而非"协议差异"——三种协议本身都能在支持国密的平台上运行，但前提是你的统一身份认证平台确实实现了 SM2 签名、SM3 摘要等国产化密码能力，并能对接鲲鹏、龙芯、麒麟、统信等信创环境。把国密适配作为选型的一项硬指标，可以避免日后为合规而推倒重来的尴尬。

技术拆解四：协议之间的转换与共存机制

当企业决定"分协议接入"后，紧接着要面对一个问题：前端用户体验能不能统一？答案是可以的，前提是统一身份认证平台具备协议转换能力。典型做法是平台对外统一暴露 OIDC（现代应用最友好的入口），对内把 OIDC 的请求翻译成后端系统认识的 SAML 或 CAS 交互。用户侧始终走一套登录页、一套交互逻辑，后端老系统完全无感。

这种"外层 OIDC、内层兼容"的架构还有个好处：它把协议差异封装在了平台内部，业务系统升级时只需在平台侧切换后端适配，不必改动前端。对于存量的只认 CAS 的轻量系统，平台也可以继续作为 CAS 服务端存在，让这些系统原地接入，零改造享受统一账号与策略。

需要提醒的是，协议转换会引入一层映射关系，最容易出问题的地方是"用户标识对齐"：OIDC 用 subject、SAML 用 NameID、CAS 用用户名，三者必须稳定映射到同一企业内部用户主键，否则会出现"同一人在不同系统被识别成不同账号"的割裂。落地时务必先建立统一用户主键，再谈协议适配。

迁移路径：从"多协议并存"走向"统一治理"

现实里很少有团队能一夜之间把所有系统迁到同一协议。更可行的迁移路径分四步。

第一步，平台先行。先上一套支持多协议的统一身份认证平台，把所有现存系统的账号目录（如 LDAP、AD）先接进来，实现"账号集中、认证仍走原协议"。这一步不动业务系统的登录逻辑，风险最低。

第二步，按场景分流接入。新业务直接上 OIDC；老牌 ERP/CRM 走 SAML；轻量内部系统走 CAS。平台同时充当三种协议的端点，对应用侧来说各自还是熟悉的协议，对管理侧来说已经是统一管控。

第三步，渐进式协议升级。对关键系统，利用平台提供的协议转换能力，在外层用 OIDC 收口、内层仍兼容旧协议，逐步把前端交互统一到 OIDC，把后端老系统的 SAML/CAS 隐藏在平台之后。这样用户侧体验一致，旧系统无需大改。

第四步，策略统一与合规收敛。当账号、认证、MFA 都在一个平台治理后，就可以统一配置口令策略、登录失败锁定、风险登录拦截，并针对等保 2.0 身份鉴别条款逐条留证。到这一步，"多协议并存"不再是负担，而是被统一身份认证平台消化掉的兼容性细节。

案例视角：一个"三代同堂"系统的接入实践

设想某企业有三类系统：十年前上线的 ERP（只认 SAML）、几年前自研的科研管理系统（认 CAS）、去年新建的对外业务门户（认 OIDC）。过去三套系统三套账号，员工要记三套密码，IT 要维护三套用户目录。

接入统一身份认证平台后，平台作为中心身份源，对 ERP 暴露 SAML 端点、对科研系统暴露 CAS 端点、对业务门户暴露 OIDC 端点。员工在任意系统登录都跳转到统一登录页，输入一套凭据即可；同时平台对远程接入认证、堡垒机登录这类高风险场景强制叠加多因素认证。管理员只需在平台一处增删改用户、配置 MFA 策略，三套系统同步生效。原本"三套账号三套密码"的混乱，变成了"一套身份、分协议适配、统一策略"的清晰结构。

这个案例里最关键的一点是：企业没有强迫任何旧系统改协议，而是用平台的多协议能力去适配它们，把迁移成本和业务中断风险降到了最低。这正是协议选型走向统一治理的正确姿势。

把视线拉长到一年维度，这种"分协议接入、平台统一治理"的架构还带来一个隐性收益：当企业未来要新增一套系统时，只需判断它支持哪种协议、在平台侧登记对应端点即可，无需重新设计身份体系；当某个旧系统退役，也只需在平台侧下线其端点，账号与策略不受影响。身份体系从"跟着业务系统走"反转为"业务系统跟着身份体系接"，治理主动权回到 IT 与安全管理团队手里。对于那些正在准备等保 2.0 测评、需要把身份鉴别条款逐条取证的团队来说，这种集中可审计的结构，比分散在各系统各自为政的登录日志要有力得多。

场景落点：十大业务场景分别该用哪种协议

把协议选型落到具体场景，会更便于决策。对于网络设备登录、堡垒机运维、服务器登录这类"后台管理"场景，往往走 RADIUS 或 SLA/SYP 这类轻量认证协议而非 SSO 协议本身，但可以复用同一套统一身份认证底座的账号与 MFA；对于云桌面、邮箱、ERP-CRM-OA 这类标准企业应用，SAML 与 OIDC 都是成熟选择，新建优先 OIDC、存量沿用 SAML；对于 Web-API 类调用，OIDC 的 Access Token 加 Scope 机制最为契合；对于 WiFi 与共享账号场景，重点不在选哪种 SSO 协议，而在用统一平台把"共享凭据"收敛为"个人身份加二次校验"，从根上治理账号共享带来的责任不清。

其中远程接入认证是一个特别值得单列的场景：员工从外部网络接入内网时，身份冒用风险最高，应当在统一身份认证平台上对该场景强制多因素认证，无论后端业务系统原本用 OIDC、SAML 还是 CAS。协议只解决"怎么通"，而远程接入这类高风险入口必须靠平台侧的策略引擎来"加一道锁"。

风险与误区：选型时最容易犯的错

误区一，盲目追新全量上 OIDC。OIDC 虽好，但你的 ERP 可能根本不支持，强行改造代价巨大。正确做法是按系统类型分协议接入，而不是用一种协议硬套所有系统。

误区二，认为 CAS 太老就该淘汰。CAS 在轻量内部系统里对接成本最低，盲目替换反而增加工作量。只要统一身份认证平台能兼容它，留着用完全合理。

误区三，只做 SSO 不做 MFA。单点登录解决了便利性，也放大了单点失陷的破坏面——一个密码泄露，全网通行。等保 2.0 下必须有更强身份鉴别，MFA 应当作为标配而非可选项。

误区四，忽略证书与元数据管理。SAML 的证书过期、OIDC 的密钥轮换、CAS 的票据有效期，都是上线后容易忘的运维点。平台应支持密钥自动轮换与过期预警，否则某天链路莫名中断，排查半天才发现是证书问题。

误区五，把协议选型当成纯技术问题。协议选型其实牵连组织架构：哪些系统归哪个部门、账号谁说了算、合规要求谁来背。技术选型之前，先要把账号治理的权责理清楚，否则平台接进来也会陷入"多头管理"的泥潭。

方案参考

做 SSO 协议选型，记住三条原则：一是按系统类型分协议接入，新建现代应用优先 OIDC、老牌企业应用保留 SAML、轻量内部系统用 CAS 兜底，不必强求三选一并存即合理；二是务必在统一身份认证平台层面叠加多因素认证，尤其对远程接入认证、堡垒机登录、共享账号使用等高风险场景强制二次校验，满足等保 2.0 身份鉴别要求；三是用支持多协议的统一平台做"兼容层"，让历史系统不改协议也能被统一治理，再渐进式把前端交互收敛到更现代的协议上。

以安当ASP为例，其作为企业级统一身份认证平台，原生支持 SAML 2.0、OAuth 2.0、OIDC、LDAP、RADIUS、FIDO2、WebAuthn 等主流协议，并覆盖 SSO、MFA、OTP、RADIUS、SLA、SYP 六大模块与网络设备、远程接入、云桌面、堡垒机、邮箱、ERP-CRM-OA 等十大场景，可在同一平台下分协议接入存量与新系统，并对国密 SM2/SM3、信创环境（麒麟、统信、鲲鹏、龙芯）提供适配，帮助企业在不颠覆既有 IT 资产的前提下，把统一身份认证和多因素认证落到等保 2.0 三级合规框架内。