身份认证系统的选型，常被简化成“支持不支持双因素”。上线后真正麻烦的，是身份从哪来、权限归谁管。员工目录、合作伙伴、设备与服务账号、外包与临时人员，这四类身份来源的管理方式差别很大，用一套流程套所有身份，迟早出问题。身份认证系统要解决的不只是登录，还包括身份从进入到退出的完整过程。
员工身份：跟着人事流程走
入转调离是身份变更的主要来源。系统要能对接人事数据，入职自动开户、调岗自动调整权限组、离职自动停用并回收应用账号。判断标准很实际：人事系统里办完离职，账号多久失效、残留的应用权限谁来清。能把这个链路打通的方案，比功能列表更值得看。账号的标识要稳定，手机号、邮箱都可能变更，用它们做主键，后续合并账号会很麻烦;离职当日停用、次日清理，这个节奏要靠流程约束，而不是靠人记得。
合作伙伴：边界要能收
供应商、经销商、代运营需要访问内部系统，但不应进入员工目录。较常见的做法是单独的外部身份空间，配合邀请制开户、访问范围限制、到期自动失效。要确认的是：外部账号能否被限定在特定应用、能否设置访问时段、合作终止后能否一次性清理。外部账号的登录行为建议单独留痕，出现异常时能快速定位是哪个合作方。
设备与服务账号：别再用人的账号跑
系统间的接口调用、自动化任务、物联网设备，往往共用一个账号，密码长期不换，权限还很大。这类身份需要有独立的凭据管理方式，比如证书、密钥对或专用凭据托管，配合定期轮换。选型时可以问：非人类身份能否单独纳管、能否设置凭据有效期、调用记录能否追溯到具体设备。服务账号的权限应单独授予，够用即可，不要沿用运维人员的角色;凭据轮换也要自动化，靠人工改密码，迟早会漏。
权限治理：认证之后才是难点
登录只是入口，真正决定风险的是登录后能看到什么。系统应支持权限申请、审批、定期复核与回收，能回答“谁在什么时候因为什么拿到了什么权限”。不少项目只做了单点登录，权限仍散落在各业务系统，审计时依旧说不清。权限模型是角色驱动还是属性驱动，也决定了后续扩展的难易。复核频率可以按权限敏感度分层，核心系统每季度过一遍，普通系统半年一次即可。
选身份认证系统，先把自己的身份来源和权限流程画出来，再看产品能不能接住。单点登录只是起点，身份治理才是长期工作。
身份认证系统的选型，常被简化成“支持不支持双因素”。上线后真正麻烦的，是身份从哪来、权限归谁管。员工目录、合作伙伴、设备与服务账号、外包与临时人员，这四类身份来源的管理方式差别很大，用一套流程套所有身份，迟早出问题。身份认证系统要解决的不只是登录，还包括身份从进入到退出的完整过程。
