Blazor Server对接OpenIdDict认证回跳死循环与POST 400错误问题

GET模式下授权死循环的本质 #

• 手动实现的授权跳转逻辑完全绕开了ASP.NET Core内置的OpenIdConnect认证管道。你在Blazor组件OnInitialized生命周期里调用NavigationManager.NavigateTo跳转到认证服务器，这个操作没有触发OIDC中间件的拦截流程，也没有生成标准的state、nonce值存入Cookie。
• 当认证服务器带着授权码重定向回应用时，请求依然会被Blazor的兜底路由匹配到/_Host根页面，因为没有经过OIDC中间件的回调处理流程，认证Cookie永远不会被写入。AuthorizeView始终识别为未授权状态，就会反复渲染GetAuthorizationCode组件、反复触发跳转，形成无限循环。

POST回调模式下400错误的本质 #

从日志的路由匹配结果可以看到：

Route matched with {page = "/_Host", action = "", controller = ""}. Executing page /_Host

• 发送到/api/Login/Callback的POST请求根本没有命中你写的API控制器，直接被Blazor Server的兜底路由规则拦截，转交/_Host页面处理。
• 因为请求进入的是Blazor页面管道，不是控制器管道，你给控制器Action加的[IgnoreAntiForgeryToken]特性完全不会生效，页面管道默认会校验 antiforgery 令牌，认证服务器POST回来的表单里没有这个令牌，就会抛出400错误。
• 路由错配的核心原因是应用启动时的终结点注册顺序错误，Blazor的兜底路由优先级被提前，截获了本该由控制器处理的请求。

1. 移除冗余的手动认证逻辑 #

• 删掉MainLayout.razor中对GetAuthorizationCode组件的引用，删除GetAuthorizationCode组件类，删除AuthService中手动拼接授权URL、触发跳转的方法。
• 你已经在服务注册中配置了完整的OpenIdConnect中间件，该中间件会自动处理未授权请求跳转、state/nonce生成与校验、授权码换令牌、身份票据写入的全流程，不需要手动实现。

2. 调整请求管道的终结点注册顺序 #

在Startup.cs的管道配置部分，必须将控制器路由注册放在Blazor兜底路由之前，提升控制器路由的匹配优先级：

app.UseEndpoints(endpoints =>
{
    // 优先匹配API控制器路由
    endpoints.MapControllers();
    // 映射Blazor SignalR Hub
    endpoints.MapBlazorHub();
    // 最后注册兜底路由，匹配所有未命中前面规则的请求
    endpoints.MapFallbackToPage("/_Host");
});

调整后，对/api/Login/Callback的POST请求会正确命中控制器，不会被兜底路由截走，此时[IgnoreAntiForgeryToken]特性才能正常生效。

3. 简化回调逻辑，适配OIDC中间件的标准流程 #

• 你自定义的LoginController回调逻辑完全可以由OpenIdConnect中间件替代。中间件默认会监听/signin-oidc路径作为POST回调地址，自动完成授权码接收、令牌交换、用户信息拉取、Cookie身份写入的全流程。
• 配套调整两处配置：
  1. 在自研OpenIddict认证服务器的客户端配置中，将允许的重定向URI设置为https://你的Blazor应用域名/signin-oidc，替换原来的自定义API路径。
  2. 修正服务端的OIDC配置，移除和中间件默认行为冲突的参数，补上缺失的scope：

.AddOpenIdConnect(options =>
{
    options.ClientId = "hereclientid";
    options.ClientSecret = "hereclientsecret";
    options.RequireHttpsMetadata = false;
    options.GetClaimsFromUserInfoEndpoint = true;
    options.SaveTokens = true;
    options.ResponseType = OpenIdConnectResponseType.Code;
    // 移除自定义的AuthenticationMethod配置，使用默认的form_post回调模式
    options.Authority = "authserver";
    options.Scope.Add("openid"); // 补上缺失的openid scope
    options.Scope.Add("email");
    options.Scope.Add("profile");
    options.TokenValidationParameters.NameClaimType = "name";
});

4. 校验管道顺序确保认证流程生效 #

在Startup.cs的管道配置中，确保认证相关中间件的注册顺序在路由映射之前：

app.UseRouting();
// 认证和授权中间件必须在UseRouting之后、MapEndpoints之前
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(...);

• 修复后流程为：用户访问应用 → 被认证中间件识别为未授权 → 自动302跳转到认证服务器 → 用户完成登录 → 认证服务器POST表单到/signin-oidc → OIDC中间件自动完成令牌交换、写入认证Cookie → 302重定向回原页面 → AuthorizeView识别到已授权状态，正常渲染受保护内容，不会再出现死循环。

内容的提问来源于stack exchange，提问作者Ivan-Mark Debono