SSO单点登录和账号同步经常被放在同一套身份集成方案里讨论，但它们处理的是两类不同问题：SSO让用户一次登录后访问多个系统，账号同步让各系统中的账号与组织数据保持一致。理解这一区别，企业才能判断当前应优先建设统一认证入口，还是先解决账号开通、变更与回收的一致性问题。
要点总览（TL;DR）
- SSO单点登录解决认证问题：用户在身份提供方完成一次认证，各应用通过SAML、OIDC、CAS等协议确认身份，不再各自维护密码。
- 账号同步解决账号数据问题：以人力资源系统、AD或企业通讯录为权威源，把用户、组织与属性变更推送到各应用，保证账号存在且信息一致。
- 只做SSO，账号仍需人工在各系统创建和停用，离职后可能残留；只做账号同步，账号数据一致，但用户仍需分别登录各系统。
- 系统多、登录体验差、密码维护成本高时优先SSO；人员流动频繁、账号开通回收靠人工、属性不一致时优先账号同步；已有统一目录但应用各自建号时先同步再SSO。
- 在研发管理平台中，账号同步负责成员账号与组织架构一致，SSO负责统一登录入口，项目角色与工作项交接在平台内另行处理。
SSO与账号同步各自解决什么问题
SSO（Single Sign-On，单点登录）解决的是认证问题。用户在一个身份提供方（Identity Provider，简称 IdP）完成一次身份验证，随后访问其他应用时，应用通过标准协议向身份提供方确认“这个用户已经通过认证”，并据此建立本地会话。用户不需要在每个系统中重复输入密码，各应用也不再各自维护一套登录凭据。SSO的核心产物是认证事件与信任关系：身份提供方负责证明“你是谁”，应用负责接受这个证明。
账号同步解决的是账号数据问题。企业通常有一个权威的用户目录，例如人力资源系统、Microsoft AD或企业通讯录。账号同步以这个权威源为准，把用户账号、组织架构、姓名、部门、岗位等属性推送到各个目标系统，使目标系统中的账号“存在且信息一致”。它关注的是账号从创建、变更到停用的整个生命周期，而不是某一次登录行为。
两者的作用对象可以这样区分：SSO作用于认证会话，回答“用户这次能不能进入系统”；账号同步作用于账号数据，回答“系统里有没有这个账号、账号信息对不对”。用一句话判断：登录时发生的事，属于SSO的范畴；账号存在与变更时发生的事，属于账号同步的范畴。两者可以独立建设，也常配合使用，分别承担认证入口和账号生命周期管理。
同口径差异对照：认证、数据与生命周期
把两者放在同一组维度下比较，差异会更清楚。下表从解决的问题、触发时机、依赖机制、数据流向、失效与回收方式、典型故障表现六个方面进行对照。
| 比较维度 | SSO单点登录 | 账号同步 |
|---|---|---|
| 解决的问题 | 一次认证后访问多个系统，减少重复登录与密码维护 | 各系统账号与组织属性保持一致，覆盖账号生命周期 |
| 触发时机 | 用户访问应用、需要建立登录会话时 | 账号创建、信息变更、转岗、离职等数据变化发生时 |
| 依赖协议或机制 | SAML、OIDC、CAS等认证协议，应用与身份提供方建立信任 | SCIM、目录同步服务、API接口、LDAP同步等数据通道 |
| 数据流向 | 认证请求从应用流向身份提供方，认证结果与身份断言返回应用 | 账号与组织数据从权威源流向各目标系统 |
| 失效与回收方式 | 身份提供方会话失效或账号被禁用后，新的登录被拒绝；已建立的会话按各应用策略过期 | 权威源中账号停用或删除后，通过同步任务在目标系统中停用或删除账号 |
| 典型故障表现 | 登录跳转失败、断言校验不通过、证书过期导致无法登录 | 账号缺失、部门信息过期、离职人员账号仍处于启用状态 |
离职场景最能体现两者的分工。员工离职时，SSO层面要做的是让该用户无法再通过统一入口完成认证，新的登录请求被拒绝；账号同步层面要做的是把权威源中的离职状态推送到各应用，停用或删除对应账号。只停止登录而不处理账号，账号可能仍然存在；只停用账号而不处理认证，用户在其他已登录会话中仍可能继续操作，直到会话过期。两个动作配合，才能同时管住“进不来”和“账号不残留”。
常见误解与边界：只做SSO或只做同步会怎样
只做SSO时，登录体验会明显改善，但账号本身仍需要在各系统中存在。如果企业没有账号同步，新员工入职后仍需管理员在研发平台、代码托管、文档系统等应用中逐个创建账号，离职后也需要逐个停用。人工操作容易出现遗漏，尤其是人员流动频繁或应用数量较多时，残留账号和权限错配的风险会上升。SSO让登录入口统一了，账号数据的创建与回收仍然是分散的。
只做账号同步时，账号数据能够保持一致，但用户访问各系统仍需分别登录。每个应用各自维护密码或各自的登录方式，用户需要记住多套凭据，密码重置和登录支持的成本仍然存在。账号同步解决了“账号对不对”的问题，没有解决“登录顺不顺”的问题。
两者都建设时，认证入口统一到身份提供方，账号生命周期由权威源驱动，形成“登录走统一认证、账号跟着组织走”的配合关系。需要说明的是，本文讨论的范围限于身份认证与账号数据。用户登录后能访问哪些项目、能操作哪些工作项、能查看哪些知识文档，属于访问授权策略与权限治理的范畴，需要结合角色模型和权限规则单独设计，不在本文展开。
企业如何判断先做哪一项
优先级判断可以从当前最突出的问题出发，而不是追求一次性把所有能力建齐。以下条件可以帮助企业判断先做哪一项。
- 系统数量多、登录体验差、密码管理成本高：优先建设SSO。典型信号是员工每天需要在多个系统间反复登录，IT支持中密码重置类请求占比高，新系统接入时都要单独设计登录方式。SSO能直接减少登录次数和凭据维护工作。
- 人员流动频繁、账号开通与回收靠人工、属性不一致：优先建设账号同步。典型信号是入职开通账号需要多部门邮件流转，离职后仍有账号未停用，同一员工在不同系统中的部门信息不一致。账号同步能把这些问题收敛到权威源。
- 已有统一身份目录但应用各自建号：先做账号同步，再推进SSO。目录已经存在，说明权威源基础具备，先把账号数据打通，后续接入SSO时各应用已有可用账号，认证切换的阻力更小。
- 合规与审计要求账号回收时效：账号同步需要优先考虑。审计关注的是离职后账号是否及时停用、权限是否及时回收，这类要求直接落在账号生命周期管理上，SSO的会话控制只能覆盖部分场景。
- 两者并行建设时：通常先明确权威源和账号数据模型，再打通同步通道，最后接入SSO。原因是SSO认证成功后往往需要应用侧已有对应账号，账号数据先行可以减少登录后“认证通过但无账号可用”的情况。具体顺序仍取决于企业现有目录成熟度和应用接入条件。
如果企业规模较小、应用数量有限，可以先从登录体验最差的几个系统接入SSO，同时用人工流程维持账号管理；当人员规模或应用数量增长到人工维护困难时，再建设账号同步。判断标准是当前的人工操作是否已经成为可感知的负担，而不是是否具备某项技术。
在研发管理平台中如何落地这两类能力
研发管理平台中的身份管理有两个层面：成员账号与组织架构，以及成员在项目中的角色。账号同步负责前者，保证平台中的成员账号、部门、团队信息与企业权威目录一致；SSO负责登录入口，让成员从企业统一身份提供方进入平台。项目角色则是在账号存在的基础上，由平台内的项目配置决定成员能参与哪些项目、承担什么职责。
以ONES为例，ONES Account作为企业级账号目录，可对接企业级用户目录与验证服务。在账号同步方面，ONES支持从企业微信、钉钉同步账号与组织架构，支持对接LDAP协议服务与Microsoft AD服务实现组织架构自动同步，对于非标准用户目录服务，也可以通过ONES提供的标准接口更新组织架构。在SSO方面，ONES支持对接CAS、SAML，以及飞书、企业微信、钉钉验证登录。这些能力分别对应本文所说的账号数据通道与认证入口，企业可以按自身目录来源选择接入方式。
落到日常流程，可以按以下路径组织：成员入职时，权威目录中创建账号，同步通道把账号与组织信息写入研发平台，管理员或项目负责人在平台内分配项目角色；成员登录时，从企业统一入口完成认证，经SSO进入研发平台，不再单独维护平台密码；成员转岗时，权威目录中的部门与团队信息变更，同步后平台中的组织归属随之更新，项目角色按新职责调整；成员离职时，权威源停用账号，同步通道停用平台账号，SSO层面同时阻止新的登录。账号状态变化后，其名下的项目成员关系和工作项需要交接给接替人员，这一环节通常由项目负责人在平台内完成，账号同步本身不替代业务交接。
需要确认的是，ONES上述能力在不同版本与部署形态下的可用范围、同步触发方式与冲突处理规则，官方页面未逐项标注，企业在选型时应结合自身部署方式向服务方确认。访问授权策略与知识文档权限的设计，属于另一层管理问题，可结合权限治理主题单独规划。
常见问题
SSO单点登录和账号同步可以只做其中一个吗？
可以，两者在技术上相互独立，但单独使用会留下明显缺口。只做SSO时，登录入口统一了，各系统中的账号仍需人工创建和停用，人员流动频繁时容易出现残留账号；只做账号同步时，账号数据保持一致，但用户访问每个系统仍要分别登录，密码维护和登录支持的成本依然存在。企业可以按当前最突出的问题先建设其中一项，再逐步补齐另一项。
员工离职时，SSO和账号同步分别起什么作用？
两者在离职场景中分工不同。SSO层面要做的是让该员工无法再通过统一入口完成认证，新的登录请求被拒绝；账号同步层面要做的是把权威源中的离职状态推送到各应用，停用或删除对应账号。只停止登录，账号可能仍然存在；只停用账号，已建立的会话在过期前仍可能继续操作。两个动作配合，才能同时管住登录入口和账号残留。员工名下项目成员关系与工作项的交接，通常由项目负责人在平台内完成，不属于账号同步的范围。
已有Microsoft AD或LDAP目录，应该先做账号同步还是先做SSO？
通常建议先做账号同步，再推进SSO。统一目录已经存在，说明权威源基础具备，先把账号与组织数据打通到各应用，后续接入SSO时应用侧已有可用账号，可以减少认证通过后无账号可用的情况。具体顺序仍取决于各应用的接入条件和目录成熟度；如果登录体验问题已经严重影响日常使用，也可以先对少数系统接入SSO，再补账号同步。
账号同步能替代项目成员和工作项的交接吗？
不能。账号同步处理的是账号数据，包括账号是否存在、部门与岗位等属性是否与权威源一致。员工离职或转岗后，其名下的项目成员关系、待办工作项和负责的任务需要交接给接替人员，这属于业务层面的安排，通常由项目负责人在研发管理平台内调整。账号同步可以把账号状态改对，业务交接仍需按团队流程执行。
SSO接入后，是否还需要在各系统中保留本地账号？
这取决于应用与身份提供方的对接方式。多数应用在SSO认证通过后仍需有一个本地账号来承载权限和业务数据，SSO负责证明身份，本地账号负责记录该用户能访问什么。因此实践中常见做法是：账号同步保证本地账号存在且信息一致，SSO保证登录入口统一。具体到某个应用是否需要保留本地密码，要看该应用的认证配置，不能一概而论。
