Blazor MSAL 登录成功却丢失 ReturnUrl 回到首页

Blazor WebAssembly 已经完成 Entra ID 登录，用户状态也正确，却从受保护页面跳回 /。ReturnUrl 在登录前确实保存过，回调时也被移除，没有认证异常。如果升级的是 Microsoft.Authentication.WebAssembly.Msal 10.0.8 至 10.0.12，应检查启动期间是否有两个调用同时初始化认证服务。

这条路径针对 redirect 登录。它不等于所有登录回首页都是 MSAL 回归；应用自行重定向、错误的回调路由和无效返回地址仍需分别检查。

同一份回调状态被消费了两次

受影响实现检查 _initialized 后创建 MSAL 服务，再 await 初始化，最后才把 _initialized 改成 true。第一个调用正在等待时，第二个调用仍会看到 false，于是再创建一份服务。

常见组合是路由组件读取认证状态，同时布局里的组件通过 BaseAddressAuthorizationMessageHandler 发 API 请求。两条路径可能分别走到认证初始化；“这些代码都在浏览器里执行”并不能避免 await 之间的重入。

回调状态包含返回地址，读取后会被移除。一个实例先拿到状态，另一个实例随后拿不到；后续流程若使用了缺少状态的实例，就会退回 Navigation.BaseUri。这种情况下登录成功与返回地址丢失会同时出现。

先记录实际 NuGet 包版本、浏览器加载的静态资源版本、登录方式以及回调页面的网络过程。不要只用 .NET SDK 版本代替客户端认证包版本，也不要把包含令牌的完整存储记录、URL 或日志发到公开渠道。

在应用渲染前完成一次认证状态初始化

对于启动时多个组件竞争的这一分支，可以在 Program.cs 建好 host 之后、RunAsync() 之前先取得认证状态。下面替换原先直接构建并运行的末尾语句，原来的服务注册保持不变：

using Microsoft.AspNetCore.Components.Authorization;
using Microsoft.Extensions.DependencyInjection;

var host = builder.Build();
await using (var scope = host.Services.CreateAsyncScope())
{
    var provider = scope.ServiceProvider
        .GetRequiredService<AuthenticationStateProvider>();
    await provider.GetAuthenticationStateAsync();
}
await host.RunAsync();

前提是工程已经按原方式注册 AddMsalAuthentication。这个调整先让已有服务完成初始化，再启动组件，避免路由认证查询与布局 API 调用在初始化阶段相撞。它不会强制弹出登录，也不应替代应用原有的未登录处理。

如果初始化失败，应保留真实错误交给启动诊断，不要吞掉异常后继续把服务当成已经就绪。启动等待时间也需要观察。已有自定义 host、服务作用域或初始化框架的项目，要把这项顺序并入原流程，不能同时构建两个 host。

还可以暂时移除布局在认证尚未就绪时的 API 调用，用于确认竞争条件。但永久删除必要请求或给它加任意毫秒延时都不稳定：机器和网络变化后，竞争仍可能回来。

验证返回地址，不改写认证状态

用退出登录后的干净流程直接进入一个受保护的深层地址，完成 redirect 登录，确认最终回到该页面。再检查刷新、重新登录、未授权访问和 API token 获取；只测试从首页点击登录，容易看不出返回地址是否丢失。

不要手工重建 MSAL 的 sessionStorage 内容，也不要信任任意查询参数中的外部返回地址。正常认证 API 应继续负责状态校验与返回路径处理，避免为修一个导航错误引入开放重定向。

截至 2026 年 10 月 20 日，避免 MSAL 并发初始化的修正已合入主线，但主线合入不是已核验的正式 10.0 补丁发布证据。后续采用包含修正的版本时，同步核对客户端包与实际部署的静态资源，防止浏览器仍运行旧脚本。撤回临时预初始化后也要重复深层地址登录流程，而不是只确认构建通过。