研发平台单点登录（SSO）是指研发平台把用户身份认证交给企业统一的身份提供方完成：用户在企业统一入口通过一次认证后，凭同一身份访问代码托管、流水线、需求管理等子系统，无需逐个重复输入账号密码。它解决“这个人是谁、是否已通过认证”，进入平台后能看哪些项目、能执行哪些操作，则属于访问授权策略。
要点总览（TL;DR）
- 研发平台单点登录（SSO）是把身份认证交给企业统一身份提供方完成，用户一次认证后可访问需求管理、代码托管、流水线等多个研发子系统。
- 单点登录解决“你是谁、是否已认证”，项目角色、工作项操作权限和知识文档可见范围属于访问授权，不在其定义范围内。
- 一次登录涉及用户浏览器、身份提供方和研发平台三方，通过 SAML 或 OIDC/OAuth 2.0 等协议传递认证结果，再由平台完成账号映射和会话建立。
- 单点登录与统一账号目录、多因素认证、访问授权是不同层面的概念，可以组合使用，但不能相互替代。
- 接入前需确认协议兼容、账号映射的唯一标识、会话与退出策略，以及认证通过后的角色权限体系是否就绪。
研发平台单点登录的直接定义
单点登录的英文是 Single Sign-On，缩写为 SSO，中文也常写作“一次登录、多处通行”。它的基本含义是：用户在一次会话中完成身份认证后，可以凭这次认证结果访问多个相互独立的应用系统，而不必在每个系统中分别登录。这里的“单点”指认证动作集中在一处，“登录”指认证通过后获得的会话状态。
在研发平台场景中，角色分工是明确的。企业通常已有统一身份提供方（Identity Provider，简称 IdP），例如企业目录服务、企业微信、钉钉或专门的统一认证系统，负责核验用户身份。研发平台则扮演服务提供方（Service Provider，简称 SP）的角色，它不自行核对密码，而是信任身份提供方给出的认证结论。用户访问研发平台时，被引导到身份提供方完成认证，认证通过后带着凭据回到研发平台，获得平台会话。
这个结果落到研发团队日常使用中，就是成员从企业统一入口登录一次，随后可以进入需求管理、代码托管、持续集成流水线、测试管理、知识文档等研发子系统，各子系统共享同一次认证结果。与普通账号密码登录的差别在于认证位置发生了转移：认证动作从“每个系统各自校验密码”变为“统一身份提供方校验一次，各系统信任该结果”。研发平台仍然保留自己的用户记录和权限体系，只是不再承担核验密码的职责。
可以用一句话概括：研发平台单点登录是研发平台以服务提供方身份接入企业统一认证，用一次认证换取多个研发子系统的访问资格。它改变的是登录入口和认证责任归属，平台内部的协作方式与权限规则继续按原有设计运行。
它管什么、不管什么：认证与授权的边界
理解单点登录，关键是分清认证与授权这两件事。认证回答“你是谁、你是否已通过验证”，授权回答“以你的身份，可以查看哪些对象、执行哪些操作”。单点登录覆盖前者，并在认证通过后完成账号映射，把企业身份对应到研发平台内的用户记录；它不决定这个用户在某个项目中是管理员还是普通成员，也不决定他能创建、编辑还是删除某类工作项。
具体来说，单点登录管的是：用户身份的核验、认证结果的传递、企业账号与平台账号的对应关系、会话的建立与失效。它不管的是：项目角色分配、工作项操作权限、流水线执行权限、知识文档的可见范围与共享规则。知识文档权限属于内容层面的权限管理，通常按页面、空间或导出等维度单独配置，与登录方式是两个层面的问题。
账号生命周期与单点登录的关系也需要说清。入职开通、离职停用属于账号治理动作：企业身份提供方停用某个账号后，该用户通常无法再通过单点登录进入研发平台，这是单点登录带来的联动效果；但平台内历史数据的归属、待办工作的交接、项目成员的调整，仍需要在研发平台侧另行处理。把账号停用等同于权限清理，是常见的越界理解。
因此，评估一套研发平台的单点登录方案时，应分别确认两件事：认证链路是否打通，以及平台内的角色与权限模型是否满足协作需要。前者决定登录是否顺畅，后者决定成员进入平台后能看到什么、能做什么。
单点登录在研发平台中的组成与运行机制
一次单点登录涉及三方角色：用户浏览器、企业身份提供方、研发平台服务提供方。用户浏览器发起访问并携带会话凭据；身份提供方负责展示登录页、核验身份、签发认证结果；研发平台负责发起认证请求、接收并校验认证结果、建立本地会话。三方通过约定的协议交互，形成完整的登录链路。
| 组成要素 | 承担角色 | 主要动作 | 产生的结果 |
|---|---|---|---|
| 用户浏览器 | 发起方与凭据载体 | 访问研发平台，跳转至统一登录页，提交认证信息 | 携带认证结果返回研发平台 |
| 身份提供方（IdP） | 认证责任方 | 核验用户身份，签发断言或令牌 | 输出“该用户已通过认证”的结论 |
| 研发平台（SP） | 信任方与资源方 | 发起认证请求，校验断言或令牌，映射账号，建立会话 | 用户获得平台访问资格 |
| 协议 | 交互约定 | 规定请求格式、签名校验、结果传递方式 | 三方按统一规则完成认证交接 |
常见协议族包括 SAML 与 OIDC/OAuth 2.0。SAML 以 XML 断言的形式传递认证结论，常见于企业级应用集成；OIDC 建立在 OAuth 2.0 的授权框架之上，用 ID Token 表达身份信息，在移动端和现代 Web 应用中较为常见。具体采用哪个协议、支持哪个版本，取决于企业身份提供方与研发平台双方的兼容情况，接入前应以双方的实际支持范围为准。
认证结果传到研发平台后，平台需要完成账号映射：用企业身份中的唯一标识（如账号名、邮箱或员工编号）匹配平台内已有的用户记录。映射规则需要在接入时确定，并保持稳定，否则同一用户可能被识别为不同账号。映射成功后，平台建立本地会话，用户在会话有效期内访问各子系统时无需再次认证。
会话有效期与重新认证是运行机制的一部分。平台通常设置会话时长，超时后要求重新认证；部分场景下会按安全策略触发再次核验。退出登录时，是仅结束研发平台会话，还是联动结束统一身份会话，取决于接入配置。这些策略影响使用体验与安全强度，需要在接入阶段与身份管理团队共同确认。
与相邻概念的区别：单点登录、统一账号、多因素认证、访问授权
单点登录经常与几个相邻概念一起出现，混用会导致讨论失焦。下面按判断要点逐项区分。
| 概念 | 解决的问题 | 与单点登录的关系 | 判断要点 |
|---|---|---|---|
| 单点登录（SSO） | 一次认证后访问多个系统 | 本文主题 | 关注认证入口是否统一、结果是否被多个系统信任 |
| 统一账号目录 | 账号与组织架构的集中来源 | 常作为身份提供方的数据基础，与单点登录配合使用 | 关注账号在哪里创建、组织架构从哪里同步 |
| 多因素认证（MFA） | 提高认证强度 | 可与单点登录组合，在认证环节增加第二重核验 | 关注认证时是否要求密码之外的额外凭证 |
| 访问授权策略 | 决定身份可执行的操作 | 在单点登录之后生效，属于平台内权限范畴 | 关注角色、项目成员、操作权限如何配置 |
| 知识文档权限 | 决定内容的可见与共享范围 | 独立于登录方式，按文档或空间配置 | 关注页面可见范围、编辑与导出权限 |
统一账号目录与单点登录的区别在于：目录解决“账号从哪里来”，单点登录解决“认证在哪里做”。企业目录服务集中存放账号和组织架构，单点登录则让各系统信任目录给出的认证结论。两者经常一起部署，但也可以分别存在：有统一目录而未接入单点登录时，用户仍需在各系统分别登录。
多因素认证加强的是认证环节本身。单点登录把认证集中到一处，如果这一处只校验密码，风险也随之集中；叠加多因素认证后，统一入口的认证强度提高，各接入系统共同受益。是否启用多因素认证，取决于企业对安全等级的要求和用户体验的权衡，属于可组合的策略选择。
访问授权与知识文档权限都在认证之后发挥作用。用户通过单点登录进入平台，只代表身份可信；他在某个项目中能否编辑需求、能否触发流水线、能否查看某篇文档，由平台内的角色与权限规则判定。把单点登录当作权限统一的手段，会让权限设计缺位。
一个具体例子与常见误解
以下为演示情景，用于说明单点登录的起止过程，不代表真实客户案例。某研发团队新成员在入职当天完成企业账号开通，账号信息进入企业统一身份系统。该成员打开企业统一入口完成登录，随后点击研发平台入口：浏览器被引导至统一认证页，由于已有企业会话，认证直接通过；身份提供方签发认证结果，研发平台校验后，按邮箱将该成员映射到平台内预建的账号，建立会话。此后他依次打开需求管理、代码托管和流水线页面，各子系统识别同一会话，不再要求输入密码。当天下午他退出统一入口，研发平台会话随之结束；次日再次访问时，重新走一次认证流程。
这个例子中，认证发生在统一入口，账号映射发生在研发平台侧，会话贯穿各子系统，退出则按配置结束会话。四个环节各有责任方，缺一不可。
常见误解之一：单点登录等于所有系统权限相同。实际上，单点登录只统一认证，各系统仍按自己的权限模型判定操作范围。同一用户在一个项目中是管理员，在另一个项目中可能只是查看者。
常见误解之二：接入单点登录后无需管理账号状态。企业侧停用账号通常能阻止再次登录，但平台内的成员关系、待办交接、历史数据归属仍需在研发平台侧维护。账号治理与认证接入是两项工作。
常见误解之三：单点登录能替代访问授权设计。认证通过只说明身份可信，若平台内角色与权限未按项目、按对象配置，成员进入后仍可能看到不该看的内容或缺少必要操作权限。授权设计需要在接入单点登录的同时同步梳理。
研发平台侧需要准备的条件与衔接点
从概念落到接入，研发平台侧需要具备几项前提。第一，平台需支持与企业身份提供方相匹配的认证协议，并完成双方配置，包括认证地址、证书或密钥、回调地址等参数。第二，需要确定账号映射规则与用户唯一标识，明确以哪个字段作为匹配依据，并保证该字段在企业侧稳定唯一。第三，需要规划会话策略，包括会话时长、超时后的处理方式以及退出登录的联动范围。第四，需要梳理认证通过后的权限衔接：用户进入工作项、项目、文档等对象时，权限仍按平台内角色判定，接入前应确认角色体系与成员管理流程已经就绪。
在工具承载层面，ONES 支持 SSO 单点登录，可对接 CAS、SAML、飞书验证登录、企业微信验证登录、钉钉验证登录，具体协议版本与兼容范围以官方最新说明为准。账号来源方面，ONES 支持从企业微信、钉钉同步账号与组织架构并通过其登录，也支持对接 LDAP 协议服务与 Microsoft AD 服务，实现组织架构自动同步与验证登录；使用非标准用户目录的企业，可通过 ONES 提供的标准接口更新组织架构。这些能力对应的是身份接入与成员账号管理环节。
认证通过之后，成员在 ONES 内进入项目、工作项与知识文档时，权限仍按平台内的角色与配置判定。例如知识库场景中，权限管理覆盖从所有页面到单个页面、从内容编辑到内容导出的不同维度与颗粒度。这与单点登录分属两个层面：前者决定“能不能进来”，后者决定“进来后能看什么、能改什么”。把两者分别规划，研发平台的身份接入才能既顺畅又不失控制。
常见问题
企业已经有统一账号目录，还需要接入单点登录吗？
两者解决不同问题。统一账号目录集中存放账号和组织架构，回答“账号从哪里来”；单点登录让各系统信任目录给出的认证结论，回答“认证在哪里做”。只有目录而未接入单点登录时，用户仍需在各系统分别登录。是否接入，取决于企业希望把登录入口收敛到什么程度，以及研发平台是否支持与现有目录对接的协议。
接入单点登录后，员工离职的账号处理还需要在研发平台侧做吗？
需要。企业身份提供方停用账号后，该用户通常无法再通过单点登录进入研发平台，这是认证链路的联动效果。但平台内的成员关系调整、待办工作交接、历史数据归属，仍要在研发平台侧处理。账号停用与权限清理是两项工作，接入单点登录不替代后者。
单点登录和多因素认证需要一起上吗？
两者可以组合，是否同时启用取决于企业的安全要求。单点登录把认证集中到统一入口，如果该入口只校验密码，风险也随之集中；叠加多因素认证后，统一入口的认证强度提高，所有接入系统共同受益。企业可以在统一入口启用多因素认证，而不必在每个研发子系统中分别配置。
研发平台接入单点登录时，账号映射最容易出什么问题？
常见问题是唯一标识不稳定或不唯一。平台通常用账号名、邮箱或员工编号匹配已有用户记录，如果企业侧同一用户的标识发生变化，或不同用户共用同一标识，就可能出现重复账号或映射错误。接入前应确定以哪个字段作为匹配依据，并保证该字段在企业侧稳定唯一，映射规则确定后保持稳定。
ONES 在单点登录和账号管理上支持哪些接入方式？
ONES 支持 SSO 单点登录，可对接 CAS、SAML、飞书验证登录、企业微信验证登录、钉钉验证登录；支持从企业微信、钉钉同步账号与组织架构并通过其登录；支持对接 LDAP 协议服务与 Microsoft AD 服务，实现组织架构自动同步与验证登录；使用非标准用户目录的企业，可通过 ONES 提供的标准接口更新组织架构。具体协议版本与兼容范围以官方最新说明为准。
