ASP.NET Core 6 Azure AD认证后本地用户持久化最佳时机

方案选型结论 #

你调研的两个方案里，订阅OnTicketReceived事件执行用户落库逻辑是官方推荐的标准实现，重定向方案确实存在可靠性缺陷，不建议使用。

为什么重定向地址方案不可靠 #

你对这个方案的判断完全准确，它的问题非常明显：

• 逻辑执行完全依赖前端跳转，用户认证完成后如果手动关闭页面、打断跳转，或者直接访问其他受保护路径绕过你配置的/Home/profile地址，落库逻辑就不会执行
• 无法覆盖所有登录入口：只要有一个登录按钮漏配了指定的重定向地址，逻辑就会遗漏
• 会话续期、令牌刷新的流程根本不会走到这个重定向地址，逻辑覆盖存在天然缺陷
• 把身份认证后的核心数据逻辑绑定到前端路由，不符合后端分层设计原则，后续维护很容易出问题

你提到的重定向方案示例代码：

<a class="nav-link text-dark" asp-area="MicrosoftIdentity" asp-controller="Account" asp-action="SignIn" asp-route-redirecturi='/Home/profile'>Sign in</a>

仅适合做登录完成后的页面跳转引导，绝对不能承载用户落库这类核心逻辑。

OnTicketReceived事件的触发逻辑说明 #

你对事件触发时机的疑问可以明确：

• 这个事件仅在用户首次完成全流程认证、授权服务器返回的身份票据（id_token）校验通过、认证中间件完成用户身份Claims构建、准备将认证票据写入本地登录Cookie之前触发一次
• 后续用户携带有效Cookie访问站点、静默刷新访问令牌、会话续期的场景，都不会触发这个事件，完全不会出现每次令牌刷新都重复执行落库逻辑的问题
• 这个事件处于认证中间件管道的核心节点，执行时机完全在后端管控，不会被前端操作绕过，是做首次登录用户存在性校验、用户基础信息落库的最佳切入位置。

你贴的事件订阅实现方向完全正确，参考代码如下：

builder.Services
  .AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
  .AddMicrosoftIdentityWebApp(options =>
  {
      builder.Configuration.Bind("AzureAdB2C", options);
      options.Events.OnTicketReceived += async context =>
      {
          // 从Azure拉取完整用户信息
          var azureService = context.HttpContext.RequestServices.GetService<IAzureService>();
          var principal = await azureService.GetProfileAsync(context.Principal).ConfigureAwait(false);

          // 持久化用户信息到本地库
          var userService = context.HttpContext.RequestServices.GetService<IUserService>();
          await userService.PersistAsync(principal).ConfigureAwait(false);
      };
  })
  .EnableTokenAcquisitionToCallDownstreamApi(new[] { "user.read" })
  .AddInMemoryTokenCaches();

实现注意事项 #

落地时记得补充两个细节避免问题：

• 一定要做幂等校验：落库前先根据Azure AD返回的用户唯一标识（通常是oid声明，对应用户在Azure AD租户内的全局唯一对象ID）查询本地库，仅当不存在对应记录时才执行插入，避免重复写入
• 事件内不要放过重的逻辑：OnTicketReceived处于认证管道执行链路中，逻辑太耗时会拉长用户登录等待时间，仅保留必要的基础信息落库即可，其他非核心操作可以放到后续请求中异步处理
• 即使后续你把内存Token缓存替换为持久化缓存（比如Redis、数据库缓存），令牌刷新流程也走独立的缓存逻辑，和OnTicketReceived事件无关，不会触发重复落库。

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