企业准备让客户用已有工作账号登录新网站，演示时点击一次就进入了页面。但上线后，老客户可能看不到原来的项目，也可能被关联到同名员工的资料。统一登录交付的关键，不只是少输一次密码，而是确认身份之后，仍能找到正确账号、历史记录和当前可用范围。
把三个问题分开确认
第一，身份服务确认的是谁；第二，这个身份对应网站里的哪个账号；第三，这个网站账号现在允许访问哪些项目。登录成功只回答了第一层，不能直接跳过后面两层。
例如，合作方员工与企业员工都可以通过同一个入口登录，但不应因此共享资料。接入前应列出实际身份来源、网站已有账号的识别方式，以及谁负责确认历史归属。如果现有账号记录本就混乱，先处理不明确的对应关系，比在上线时按姓名自动合并更可靠。
OpenID Connect 是基于 OAuth 2.0 的身份层，提供可验证的身份信息；对方说“支持 OAuth”，不足以证明现有登录、账号信息和退出需求都已覆盖。要根据实际服务能力和已选协议核对，不能把标准名称当作完成证明。
用一张对应表暴露容易误合并的情况
以下为虚构样例：身份来源 A 的用户标识 U17 已对应网站账号 W42，W42 有客户甲的项目记录。表中的代号仅用于说明，不是真实账号。
| 后来发生的变化 | 应先核对什么 | 不能直接采取的做法 |
|---|---|---|
| A／U17 更换了邮箱 | 稳定身份与 W42 的关联是否仍有效 | 因邮箱变化重新创建一个无历史账号 |
| 来源 B 也返回标识 U17 | 身份来源是否不同，是否有获准关联依据 | 只看 U17 相同便接入 W42 |
| 新员工使用旧员工曾用的邮箱 | 是否新身份、交接权限由谁批准 | 把旧员工全部资料自动交给新员工 |
| 首次登录找到两条候选旧账号 | 各自历史归属与关联证据 | 随意选第一条或直接合并 |
在 OpenID Connect 中，应结合身份签发方与主体标识识别用户，即常见的 iss 与 sub；邮箱、手机号和姓名不具有同样的稳定唯一保证。企业不必记住字段名，但要知道“来自哪里”和“该来源中的哪个人”需要一起判断。
接入不同应用或更换身份服务时，还要重新确认标识对应规则，不能假设同一个自然人在所有应用都返回相同代号。历史映射应能追溯来源和确认过程，而不是靠显示姓名猜测。
首次关联应当有成功、待确认和冲突三条路
对于已经有可靠映射的账号，登录后进入原有项目；对于没有旧账号且允许新建的身份，可以按约定建立新账号，但不要无依据授予客户项目权限。对于候选冲突或无法证明归属的情况，应进入可理解的确认流程，说明需要补充什么和由谁处理。
例如，客户认为旧账号属于自己，可以通过获准的原账号验证或人工核验完成关联；不应只因为新身份返回了同一个邮箱，就无声合并。在不能确认时，既不要泄露候选账号的项目细节，也不要把失败伪装成关联完成。
关联还应可审计：记录何时把哪个来源身份对应到哪个网站账号，由何种获准流程确认。若发现错误，需要有受控纠正路径，先限制误访问，再核对受影响的资料与操作；不宜直接删除账号来“恢复干净”，因为这可能破坏业务历史。
人员变化后，已有登录状态也要检查
假设 U17 调离项目，网站能否及时撤销其项目访问，取决于角色和成员关系如何更新。仅在首次登录时复制权限，可能让之后一直在线的会话继续使用旧范围。需求应约定变更来源、同步方式及可接受的生效时效，并用实际访问验证。
身份来源停用 U17，也不自动证明网站里的所有会话当场失效。需要分别测试新的登录、已打开页面后的继续操作和直接附件访问。若项目要求在约定时限内阻断访问，实施方应证明相关机制确实覆盖这些路径，不能只展示“身份后台已停用”的截图。
账号停用、项目交接和历史记录保留是不同动作。新接手人员应取得经批准的访问范围，过去由 U17 完成的操作仍保留真实归属。已下载到本地的资料也不会因网站停用而自动消失，这属于另一个管理边界。
退出当前网站，不一定退出所有应用
客户点击“退出”后再次点登录，可能被仍有效的身份服务会话直接带回来。这不必然代表网站退出按钮没执行，而可能是退出范围只包括当前网站。页面应准确说明行为，尤其在共享设备上，不能让客户误以为所有关联服务都已退出。
OpenID Connect 的 RP-Initiated Logout 规范提供了网站请求身份提供方退出的机制，但是否支持、其他应用是否收到退出通知，还需看实际集成。验收应分别检查当前网站退出、身份服务退出以及再次进入其他应用的结果，不用一个笼统的“单点退出”标签代替证据。
用受控故障检查用户能否恢复
在获准测试环境让身份服务不可用，或让首次关联缺少必要信息，检查页面是否说明暂时无法完成、已有填写是否合理保留、求助入口是否可用。不能为减少报错直接绕过身份核验，也不能把任何备用入口自动赋予同等权限。备用方式需要独立认可的身份核验和授权规则。
交付至少覆盖：已关联老账号、允许建立的新账号、冲突候选、邮箱变更、角色撤销、身份停用、退出及服务异常。每个样例记录预期网站账号、允许的资料和实际结果。使用虚构项目与测试身份，不在公开报告中贴可用凭证、密钥或完整客户身份信息。
最终再让客户从常用业务入口进入，而不只从开发测试页登录。能找到原来的项目，不能查看无权资料，发生异常知道如何处理，才是统一登录真正帮助业务的结果。
网站需要衔接已有员工或合作伙伴账号，可私聊客服说明身份来源、旧账号情况和资料归属，沟通关联、权限变化与验收范围。
技术参考：OpenID Connect Core 1.0；OpenID Connect：RP-Initiated Logout 1.0。
