为什么一个 OTP 覆盖不了 Wi-Fi、VPN 和镜像仓库

单点登录承诺一个身份和更少的提示，而这个承诺在第三个协议上就会破裂。陷阱在于假定一次成功的认证会产出一个其他所有协议都能出示的令牌。Wi-Fi 准入、VPN 入口和容器镜像仓库各自执行不同的交换，受众和生命周期都不同。共享账号是目录层面的决定；共享凭据是协议层面的决定，而协议之间很少达成一致。

三种交换，三个归属

企业 Wi-Fi 在 802.1X 中运行 EAP 方法，通常由对用户或设备有自己看法的 RADIUS 服务终结。VPN 网关通过自己支持的那套流程完成认证，然后用自己的重认证计时器维持会话。镜像仓库会以挑战回应未认证的请求，挑战中指明令牌服务、受众和范围，客户端则用凭据换取一个短期令牌。

这不是同一个会话的三种视角。每一种都有自己的校验方、自己的生命周期和自己的吊销路径，所以目录里改一次密码，可能让其中一个继续可用，另一个却坏掉。请把它们当作恰好共用一个用户目录的三套集成。

浏览器 SSO 能带什么、不能带什么

身份提供商处的浏览器会话确实有用：重定向到那里的应用会继承用户已经完成的登录。之所以成立，是因为那些应用讲的是同一套重定向和令牌协议，也接受同一个受众。讲 EAP 的请求方没有可跟随的重定向，而收到镜像仓库挑战的 Docker 客户端要的并不是 OIDC 身份令牌。身份提供商只能为它被造出来讲的那些协议作担保。

知道该看哪里之后，故障在日志里很容易被发现。身份提供商报告登录成功，Wi-Fi 关联却依旧失败；或者浏览器从未见过的那次令牌交换之后，镜像仓库返回 401。两次成功和一次失败并不矛盾；那是三次彼此独立的认证。

证书在哪里取代反复输入的验证码

对受管设备来说，基于证书的 EAP 去掉了人的步骤，却没有去掉身份：设备出示证书，RADIUS 服务向签发机构核验，吊销也在该机构发生，而不是发生在共享密钥里。代价是生命周期的工作，因为证书会过期，必须在到期之前完成续期。

镜像仓库也有对应的划分。交互式用户可以登录一次，让凭据助手保存得到的令牌；自动化则应使用范围很窄的服务凭据或工作负载身份。两者都不该被复制进流水线的人类一次性验证码。凭据助手保存的是面向特定仓库受众的令牌，所以没法靠编辑配置文件把它改指向 VPN 网关。

docker login registry.example.com

比较维护成本，而不是提示次数

共享凭据看起来便宜，因为这份工作直到出事之前都是隐形的。换个算法：一年里每种选项要花多少——注册、续期、吊销、泄露的波及范围，以及有人离职时要改动的系统数量。证书舰队建设更贵、大规模运营更便宜；复制来的验证码起步不花什么，收尾却要付出一切。

然后按每一段分别选择，而不是全局一刀切。Wi-Fi 可以转向证书，VPN 可以保留受支持的 SSO 加 MFA，镜像仓库可以用带明确范围的令牌。为每一段记录归属方、受众、范围、到期和吊销路径，提示就会落在该落的地方，而不是同时铺满所有地方。当审计员问哪些系统还在信任密码时，这份记录也是答案。