企业内部往往有数十个业务系统：OA、ERP、CRM、代码仓库、监控平台、邮件。员工记忆多套密码既低效又不安全，密码复用还会扩大泄露风险。单点登录（SSO）让用户一次登录即可访问所有授权系统，是企业身份基础设施的核心。本文系统讲解SSO原理与主流协议，帮助上海技术团队规划统一身份认证体系。

一、SSO的核心思想

身份认证与业务服务分离

传统模式下每个系统各自维护账号密码，用户在每个系统独立登录。SSO将认证能力集中到统一身份提供商（IdP），业务系统（Service Provider）不再存储密码，只校验IdP签发的凭证。用户登录IdP后，访问任一业务系统时，系统重定向到IdP验证身份，确认后带凭证返回。这种模式让密码只在一处存储，安全边界清晰。

会话共享与票据传递

SSO的关键是跨域会话共享。用户在IdP登录后，IdP域种下会话Cookie；访问业务系统时，业务系统通过重定向携带用户标识向IdP换取票据（Ticket或Token），IdP确认会话有效后签发短期凭证。业务系统验证凭证签名后建立本地会话。整个过程中密码不出IdP域，业务系统永不接触用户密码。

二、主流协议对比

OAuth2.0：授权框架而非认证协议

OAuth2.0是授权框架，解决"第三方应用代表用户访问资源"的问题（如用微信登录第三方网站）。它定义了四种授权模式：授权码模式（Web与移动端标准）、客户端模式（服务间调用）、密码模式（不推荐）、隐式模式（已废弃）。OAuth2.0本身不做身份认证，只做授权。上海团队在使用OAuth2.0时必须清楚这一点，不能用Access Token做身份判断。

OIDC：在OAuth2.0上增加认证层

OIDC（OpenID Connect）在OAuth2.0基础上增加ID Token，JWT格式的ID Token包含用户身份声明（sub、iss、aud、exp等）。OIDC是现代Web与移动应用SSO的事实标准，支持授权码流程加PKCE（公共客户端防拦截）、UserInfo端点获取用户资料。上海新建系统应优先选择OIDC，而非自行设计认证流程。

SAML2.0：企业联邦身份的老牌协议

SAML2.0基于XML，是传统企业SSO的主流协议，广泛用于与Office 365、Salesforce、各类企业SaaS对接。IdP与SP之间通过POST绑定传递SAML断言（Assertion），数字签名保证完整性。优点：标准化程度高、企业级联邦成熟；缺点：XML笨重、调试困难、不适用于移动端Native App。上海企业对接外部SaaS时通常需要支持SAML。

CAS：高校与传统企业经典方案

CAS（Central Authentication Service）是耶鲁大学开源的Web SSO协议，票据（Ticket）机制简单：用户访问应用被重定向到CAS Server登录，登录后带Ticket回应用，应用后端用Ticket向CAS Server换用户信息。优点：部署简单、适合内部Web系统；缺点：不适合移动端与API、生态相对封闭。上海传统内部系统改造可平滑迁移到OIDC。

三、Token设计与安全

Access Token与Refresh Token

Access Token是短期凭证（建议15至60分钟），JWT格式，业务系统本地验签无需每次调用IdP；Refresh Token是长期凭证（天级），存于安全存储，用于Access Token过期后静默换新。这种双Token机制既保证短期泄露风险小，又避免用户频繁登录。上海团队应避免将Access Token设为长期有效，否则被盗后无法快速失效。

JWT的无状态局限

JWT无状态意味着签发后无法主动失效。登出时必须配合黑名单（Redis记录已注销Token）或缩短有效期。上海团队应注意JWT不应存储敏感信息（payload是Base64编码非加密），且必须验证签名、issuer、audience、expiration四项声明，不能只解码读取内容就信任。

四、架构设计与组件

统一IdP核心能力

企业IdP应具备：账号目录（对接HR系统自动入职离职）、多因素认证（MFA：短信、TOTP、硬件密钥）、密码策略（复杂度、定期轮换、泄露密码库校验）、登录审计日志。上海团队可选择开源IdP（Keycloak、Authelia）或商业方案自建，关键是与企业组织架构联动。

API网关统一鉴权

微服务架构下，每个服务自行验JWT重复且易出错。应在API网关统一校验Token合法性，解析用户身份后传递给下游服务。下游服务只信任网关传递的用户上下文，不直接面对外部Token。这种集中式鉴权让上海团队可统一实施风控、限流、审计策略。

五、高级能力与联邦

外部身份联邦

企业员工可能已有企业微信、飞书、钉钉账号，客户可能用微信、Google账号登录。IdP应支持作为联邦客户端对接这些外部身份源，用户无需在企业系统再注册一套。上海团队在设计时应区分员工身份（内部IdP+HR目录）与客户身份（外部IdP+自助注册），避免混在一个目录。

多因素认证与风险登录

密码已不再是充分认证。MFA要求用户在密码外提供第二因素：动态验证码、推送确认、硬件密钥、生物特征。高风险操作（异地登录、改密、转账）应强制MFA。上海团队应基于登录环境（IP、设备、时间）做风险评估，低风险免MFA、高风险强制MFA，平衡安全与体验。

六、常见坑点

会话管理混乱

常见错误：业务系统自己维护长期会话Cookie、登出只清本地会话不通知IdP、Token存LocalStorage易被XSS窃取。上海团队应统一会话管理：Access Token存内存、Refresh Token存HttpOnly Secure Cookie、登出时调用IdP注销端点清除全局会话。

过度定制认证流程

很多团队自行设计登录页面与票据逻辑，结果引入安全漏洞。建议上海团队直接使用IdP提供的标准登录页（托管登录），不自建前端，既安全又维护成本低。定制需求通过IdP主题配置实现，不要绕过标准协议。

七、上海团队落地路径

分阶段建设

第一阶段：选开源或商业IdP，先接入1至2个核心内部系统，跑通OIDC登录。第二阶段：推广到全部内部系统，建立MFA与登录审计。第三阶段：对接外部SaaS（SAML联邦）与客户身份体系。上海团队应避免一次性大集成，小步接入、逐步替换老旧系统。

单点登录是企业身份基础设施，不是简单的技术对接。对上海企业而言，选择标准协议（OIDC为主、SAML兼容外部）、集中IdP、统一网关鉴权，才能既提升员工体验又保障安全。建议上海团队将SSO作为零信任架构的第一步。

七、常见登录攻击与防护

CSRF、会话固定与凭据填充

CSRF攻击利用用户已登录的Cookie发起伪造请求，防护手段是SameSite Cookie属性加CSRF Token。会话固定攻击在用户登录前植入会话ID，登录后不更换，防护是登录成功后重新生成Session ID。凭据填充（Credential Stuffing）用泄露的账号密码库批量尝试登录，防护包括：登录失败限流、异常IP与设备告警、强制MFA、密码泄露库校验（用户设置密码时检查是否在已知泄露库中）。上海团队应在登录接口集成这些防护，不能只依赖密码本身。

注销与全局会话终止

用户登出时不仅要清除本地Cookie，还要调用IdP的全局注销端点（End Session Endpoint），让IdP销毁全局会话，防止用户在公共电脑上未注销被他人继续访问。移动端登出应同时注销Refresh Token。上海团队应建立会话审计：异常登录、异地登录、新设备登录时主动通知用户，支持一键下线所有会话。