统一认证的难点不在协议，而在"谁说了算"。账号从哪来、谁批权限、离职谁负责停——这三件事不定，接再多协议也只是把混乱集中了。
一、先盘点：你到底有多少套账号
做统一认证之前，先出一张账号台账：系统名、用户数、账号来源、认证方式、是否支持标准协议、负责人。
- 支持 OIDC / SAML / LDAP 的，可以直接接
- 只有自建账号体系的，要改造或做适配层
- 厂商黑盒、无法改造的，只能保留独立登录，别硬接
盘点完通常会看到一个事实：真正需要单点登录的核心系统可能只有五六个，其余都是低频工具。先接高频的，收益最明显。
二、协议选型：别追新，看谁能对接
| 协议 | 适合 | 说明 |
|---|---|---|
| OIDC / OAuth2 | 自研 Web、移动端、小程序 | 现代首选，JSON 交互，接入成本低 |
| SAML 2.0 | 成熟商用 SaaS、海外软件 | 配置繁琐但兼容性最好 |
| LDAP / AD | 内网系统、NAS、打印机、VPN | 本质是目录服务，不是单点登录，常与前者并存 |
| CAS | 历史遗留 Java 系统 | 改造量小，逐步替换即可 |
现实里往往是"一套身份源 + 多种协议出口"。别指望所有系统统一到一种协议，那不现实。
三、账号主数据：以 HR 为准，别以 IT 为准
账号的增删改必须有唯一权威来源，通常是 HR 系统或人事台账。落法：
- 入职：HR 建档 → 自动创建主账号 → 按岗位模板分配默认应用
- 调岗：HR 变更 → 触发权限复核，超出新岗位的权限自动回收
- 离职：HR 状态变更 → 当日禁用主账号 → 下游系统统一失效
如果 HR 数据不可靠，退一步用"IT 台账 + 每月与 HR 对一次"，但对账必须有人签字。没有主数据，统一认证只会把"到处有账号"变成"到处有同一个错账号"。
四、权限模型：角色够用就别上 ABAC
- 应用授权：谁能登录哪个系统，按部门或岗位批量授权
- 角色：系统内角色仍由各业务系统自己管，统一认证不接管细粒度权限
- 组：与 AD 安全组或 HR 组织架构对齐，减少手工维护
常见误区是把业务权限也收进统一认证，结果每加一个功能就要改认证平台，反而更慢。认证平台管"你是谁、能进哪个门"，门里的事交给业务系统。
例外账号要单独登记
外包、驻场、共享账号必须走独立流程，设到期日，禁止并入普通员工目录。这类账号是审计里最容易被点名的地方。
五、切换期：双轨、灰度、回退
- 先接一个非核心系统试运行两周，验证登录、登出、超时、改密四条链路
- 核心系统切换前保留原登录入口，双轨运行一个完整业务周期（如一次月结）
- 准备回退方案：认证平台故障时，管理员账号可本地登录应急
- 切换完成后关闭旧入口，但要留下"应急账号"并纳入密码托管与审计
最后是运维：认证平台本身成了单点，可用性要求比任何一个业务系统都高。至少做主备，并把它放进最高级别的监控里。
#统一认证#单点登录#SSO#行业解决方案
