Azure AD B2C刷新id_token时重建已删除用户为“unknown”用户？

首先可以明确：你遇到的这个情况绝对是异常的，完全不符合Azure AD B2C的设计逻辑。正常来说，当用户账户被删除后，该用户的所有身份凭据（包括refresh token）都会被立即失效，根本无法用来请求新的id_token/access token，更不会触发用户账户的重建。

为什么这是异常？ #

Refresh Token的核心作用是在用户无需重新登录的前提下，获取新的短期令牌，但它的有效性完全依赖于用户账户的存在性与权限状态：

• 用户被删除后，Azure AD B2C应该拒绝任何来自该用户refresh token的请求，返回类似invalid_grant或user_not_found的错误
• 绝对不应该因为一个失效的refresh token请求，就自动重建用户账户，更不该出现名称为unknown的异常用户条目

可能的触发原因分析 #

结合你描述的现象（邮箱一致、名称为unknown、审计日志指向id_token请求），常见的诱因有这几种：

• 软删除未彻底清理：Azure AD B2C默认对删除的用户执行「软删除」，用户会进入回收站保留30天。如果此时用旧的refresh token请求令牌，B2C可能误将软删除的用户恢复，但因为部分用户属性未同步，导致名称显示为unknown
• 缓存机制异常：B2C的令牌验证缓存可能未及时更新用户删除状态，导致旧refresh token被判定为有效，进而触发了用户账户的自动重建（这属于服务端的bug类问题）
• 自定义政策配置漏洞：如果你的应用使用了Azure AD B2C自定义信任框架政策，可能在用户旅程的令牌刷新阶段，配置了自动创建/恢复用户的逻辑（比如未检查用户状态的AAD-UserReadUsingEmailAddress技术配置文件）

排查与解决步骤 #

1. 确认用户删除类型 #

登录Azure门户，进入你的B2C租户的「用户」→「已删除的用户」，查看该邮箱对应的用户是否处于软删除状态：

• 如果是软删除，直接选择该用户执行「永久删除」操作，彻底清除账户后再测试refresh token是否失效
• 如果已经是永久删除状态，那基本可以确定是服务端或配置的问题

2. 深挖审计日志细节 #

找到触发用户重建的那条id_token请求日志，重点查看：

• 请求中的client_id（确认是你的移动应用发起的请求）
• refresh_token的关联用户ID（确认对应已删除的账户）
• 操作的「状态原因」，看是否有明确的错误或异常标记

3. 手动验证Refresh Token有效性 #

用Postman或curl手动调用B2C的令牌端点，模拟移动应用的请求：

POST https://<你的B2C租户>.b2clogin.com/<你的B2C租户>.onmicrosoft.com/<你的政策ID>/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=<你的应用客户端ID>
&refresh_token=<问题中的refresh token>
&scope=<你的应用权限范围>

如果请求成功并返回新令牌，同时用户被重建，那这肯定是需要上报的异常问题；如果返回错误，可能是移动应用端的缓存refresh token未更新。

4. 检查自定义政策（如果使用） #

如果你的应用依赖自定义信任框架政策，检查用户旅程中处理令牌刷新的步骤：

• 查看是否有AAD-UserReadUsingEmailAddress或类似的技术配置文件，是否添加了检查用户状态的逻辑（比如过滤掉软删除的用户）
• 确保在令牌刷新阶段，没有自动创建用户的逻辑（比如AAD-UserWriteUsingEmailAddress这类步骤只在注册流程中触发）

5. 联系Azure支持 #

如果以上步骤都无法解决问题，这大概率是Azure AD B2C的服务端异常，需要提交支持工单，提供以下信息：

• 租户ID、用户邮箱、异常用户的对象ID
• 审计日志的完整详情（包括时间戳、请求ID）
• 手动测试refresh token的请求与响应结果

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