先说结论：WMS、OMS、TMS 三个系统要做 SSO 单点登录，先别急着翻协议文档。先花一个下午，把一张三列表画出来——第一列是人名，第二列是他在每个系统里的角色，第三列是他离职时谁负责关账号。这张表画不出来，SAML 和 OIDC 选哪个都白搭。这个坑我见过三次，每次翻车点都在同一处：身份提供方这边接通了，业务这边的权限映射还是一笔乱账。
账号这事，为什么总在上线前夜炸
2023 年 9 月，南加州一个 6 万平方英尺的 3PL 仓，WMS、OMS、TMS 三个系统同周上线。甲方图省事，给一线定了统一账号密码，三个系统同一套登录。听起来很美，对吧？
上线第三天就炸了。客服小姑娘在 OMS 里能看订单，也能在 TMS 里改承运商报价——因为三个系统的客服角色权限定义完全不一样，共用一套账号之后，权限最宽的那个系统成了事实上的权限上限。甲方老板问我：这不就是单点登录吗，怎么越登越乱？我回他：你们做的不是单点登录，是单点送命。
救回来的办法很土，但有效：连夜冻结了 40 多个跨系统共用账号，按人、系统、角色重建了 120 个独立账号，先让业务跑起来；再花两周把三个系统的角色矩阵对齐，接到统一的身份源上。这个项目让我记住一句话：单点登录解决的是你是谁，单点权限解决的是你能干什么——这是两件事，永远别把后者外包给前者。
共用账号还有个更隐蔽的代价：审计黑洞。2024 年旺季，另一个仓的 TMS 里一笔运费被人改低了，查日志只看到操作人是 dispatcher01 这个公共账号——可当天有 6 个调度员轮班用过这台电脑，最后谁也说不清是谁点的。SSO 之后，每个操作都精确到人，甩锅空间直接清零。这也是我坚持先盘账号再谈协议的原因：账号不清，日志就是废纸。
分步做法：从零到 SSO 上线的清单
第一步：盘账号。把三个系统现有的全部账号导出来，列成三列表格：账号名、所属系统、当前角色。重点标出三类账号——离职员工的僵尸账号（几乎每个项目都有 5%～10%）、多人共用的公共账号（拣货平板上最常见）、权限超标的万能账号。这三类不上线前清掉，SSO 接了等于白接。
第二步：画角色映射表。行是业务角色（拣货员、客服、调度员、仓库主管、财务、IT 管理员），列是三个系统，单元格里写这个角色在该系统里到底能点哪些按钮。注意：TMS 的调度员和 WMS 的调度员大概率不是一回事，名字一样不代表权限一样。这张表要业务负责人签字，不签字不上线。
第三步：选身份源。公司如果已经在用统一的身份管理，直接拿它当身份提供方，不要另起炉灶。没有现成的，才走第四步的选型。
第四步：定协议。新系统优先 OIDC，老系统先看支不支持 SAML 2.0。很多传统 WMS 只认 SAML，别硬上 OIDC 去改人家代码——协议适配的坑比你想象的深。
第五步：配用户属性映射。定好身份提供方往下游系统传哪些字段：工号、邮箱、部门、角色。至少传一个全局唯一的稳定标识，推荐工号，不要用邮箱——邮箱是会改名的。每个字段写清楚谁是权威源，比如部门以 HR 系统为准。
举个例子：工号 1047 的拣货员调岗去做客服，HR 系统里部门一变，身份提供方下次同步就把他在 WMS 的拣货角色收回、OMS 的客服角色加上，全程不用 IT 手工改。权威源定错了就会反过来：曾经有个项目把部门权威源设成了 WMS，结果 HR 调岗之后 WMS 没人维护，权限三个月没变，等于白做。
第六步：定离职和调岗流程。账号禁用必须跟 HR 的离职流程挂钩，目标是离职当天自动禁用。做不到自动，至少每周五下午 IT 人工核对一次离职名单。这个坑我见过三次：2024 年初，一个做家居电商的自营仓，SSO 上线半年后做权限审计，才发现某离职三个月的调度员账号还能进 TMS 查运价——HR 的离职名单从来没人同步给 IT。
第七步：灰度上线。先拿 IT 部门 5～10 个人试点一周，再扩到一个仓库，最后全量。试点期间保留原账号登录入口做回退——上线前夜 checklist 里，这一条永远置顶。
先算账：SAML、OIDC 还是自建账号
| 维度 | SAML 2.0 | OIDC | 自建账号体系 |
|---|---|---|---|
| 适合对象 | 老系统、传统 WMS/ERP | 新系统、云原生应用 | 只有一两个系统的小团队 |
| 实施工作量 | 中等（XML 配置繁琐） | 较低（JSON，生态成熟） | 前期低，后期维护高 |
| 维护成本 | 低（标准成熟） | 低 | 高（密码策略、审计、MFA 全得自己写） |
| 移动端/平板支持 | 弱 | 强 | 看你自己写得怎么样 |
| 长期总账 | 协议老但稳 | 新项目的默认选项 | 系统一多就亏，三个以上别碰 |
决策框架很简单：三个系统里有一个只支持 SAML，那就全线 SAML；都是新系统就 OIDC；只有当你确定未来两年系统数量不会超过两个，才考虑自建。自建账号体系最大的成本不是开发，是三年后接第四个系统时，你发现前面三个的密码策略各写了一套。
实施周期给个参考量级：三个系统接同一家身份提供方，有专人配合的话 2～4 周能跑通；角色矩阵对齐通常比技术对接更花时间，留足两周给业务部门扯皮——别问我怎么知道的。
上线前夜 checklist：翻车点都在这里
- 测试账号删干净没有。几乎每个项目，上线前夜都能扫出三五个 test01 之类的账号还活着。
- 管理员账号走不走 SSO。建议每个系统至少保留一个本地超级管理员账号，身份提供方挂掉的那天能救命。密码写纸上锁保险柜里——对，就是这么土，但真救过命。
- 会话超时时间三个系统统一了没有。WMS 设 8 小时、TMS 设 30 分钟，调度员会疯。建议统一成 4～8 小时，旺季平板不锁屏的场景单独配策略。
- 断网场景测过没有。仓库 Wi-Fi 死角里，平板上的 SSO 跳转页打不开，拣货员就站在货架前干瞪眼。弱网和断网的降级方案必须实测。
- 审计日志能不能串起来。出了事要能回答张三昨天下午两点在 TMS 里改了什么，三个系统的日志都得带上统一的用户标识。
- 手持 PDA 的登录体验单独测一遍。PDA 屏幕小、扫码枪是输入主力，SSO 的跳转加输密码流程在 PDA 上经常卡住。建议给 PDA 配证书或设备级信任登录，别让拣货员在小屏幕上输 12 位复杂密码——输三次输不对，他就会把密码写在 PDA 背面，你猜我怎么知道的。
最后说个反常识的：很多人觉得上了 SSO 就安全了。恰恰相反——SSO 把一把钥匙开一扇门变成了一把钥匙开三扇门，钥匙丢了损失是三倍。所以 MFA 不是可选项，是 SSO 的标配。嫌麻烦？那至少给管理员和财务角色强制开 MFA。
明天就能动手的一件事：把三个系统的账号导出来，按第一步的三列排一遍。你会发现的第一个真相通常是——你以为的 80 个账号，实际有 110 个。
作者：林晓｜WMS 实施顾问，做过 30+ 上线项目
