现有用户名密码登录Web应用如何兼容Azure AD单点登录

首先直接给结论：不建议你存储sub+tid的拼接值作为用户匹配依据，这个方案有潜在的稳定性问题，下面说明原因和更合理的实现方式。

为什么sub+tid不是最优选择 #

sub声明是应用级别的用户标识，仅对你当前在Azure AD中创建的这一个应用注册（App Registration）唯一。如果你后续出现以下操作，同一个Azure AD用户拿到的Token里的sub值会发生变化，之前存的绑定关系会直接失效：

• 删除现有应用注册重新创建
• 调整应用注册的租户模式（单租户切多租户、再切回单租户）
• 微软侧对应用注册做底层标识迁移（官方文档明确标注过sub不保证跨应用实例永久不变）

换句话说，sub是给当前应用识别用户用的，不是给业务系统做用户身份永久绑定用的。

推荐实现方案 #

用oid+tid的组合做身份匹配，这是Azure AD官方推荐的跨应用、永久不变的用户唯一标识：

• oid：用户对象ID，是Azure AD中用户实体本身的全局唯一ID，只要用户不被删除、不跨租户迁移，这个值永远不会变，和你接多少个应用、怎么改应用注册配置没有关系
• tid：租户ID，标识用户所属的Azure AD租户，多租户场景下用来区分不同租户下可能重复的oid

具体落地步骤 #

• 数据库调整
  不要存拼接字符串，单独新增两个字段即可：
  • AzureTenantId：字符串类型，存储Token中的tid值
  • AzureObjectId：字符串类型，存储Token中的oid值
    给两个字段加联合唯一索引即可，比存拼接值灵活很多，后续做多租户统计、批量查询、对接其他Azure服务都方便。如果你的站点只服务单个Azure AD租户，甚至可以只存AzureObjectId，但建议预留AzureTenantId字段，避免后续扩展时改表。
• 账号绑定逻辑
  不要给SSO登录的用户自动创建新账号，避免和原有账号体系冲突：
  • 老用户首次走SSO：先跳转到原用户名密码登录页，校验通过后把当前Token里的tid、oid和该用户账号绑定，后续就可以直接走SSO登录
  • 新用户走SSO注册：校验Token合法后，先查库确认没有对应tid+oid的绑定记录，再走新用户创建流程，同时写入两个字段值
• 登录校验逻辑
  每次Azure AD返回Token后，先完成标准的Token签名、颁发者、受众校验，确认Token合法后再提取tid和oid查库：
  • 查到绑定的用户记录：直接启动对应用户会话，和你原有用户名密码登录后的会话、权限逻辑完全复用，不需要额外调整
  • 查不到绑定记录：跳转到账号绑定/注册引导页，不要直接放行进入系统

❗ 避坑提醒：绝对不要用upn（用户主体名，格式类似user@company.com）、邮箱声明作为用户匹配依据，这两个值都是租户管理员可以随时修改的，用户修改UPN/邮箱后你就匹配不到原有账号，会出现权限错乱、账号找不到的问题。

内容的提问来源于stack exchange，提问作者Psychonaut007