修改重定向URI后无法通过ITokenAcquisition获取访问令牌的问题

1. 为何修改重定向后无法获取令牌？ #

核心原因是手动修改redirect_uri破坏了OpenID Connect认证流程的一致性：

• Azure AD会严格校验授权请求中的redirect_uri与应用注册中配置的地址是否完全匹配，哪怕域名相同，若请求时的redirect_uri和回调时实际接收的地址存在隐含差异（比如中间代理的头信息未被正确识别），会导致授权码无效，后续无法交换令牌。
• ITokenAcquisition依赖认证过程中保存的上下文信息（如state参数、认证会话中的redirect_uri），手动修改后，上下文里的redirect_uri与后续令牌请求时使用的地址不一致，导致缓存无对应条目或请求被拒绝。
• 手动设置redirectUri会覆盖OpenID Connect中间件自动生成的、与state参数绑定的地址，回调时无法完成状态验证，认证流程未完全完成，自然无法获取到用户令牌。

2. 推荐的替代方案 #

无需手动修改redirect_uri，通过配置反向代理转发头，让ASP.NET Core自动识别Front Door的原始请求地址，从而生成正确的重定向URI：

步骤1：配置Forwarded Headers中间件 #

在Program.cs中添加转发头配置，让应用识别Front Door传递的原始请求信息：

var builder = WebApplication.CreateBuilder(args);

// 添加Forwarded Headers配置
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    // 可选：添加Front Door的IP地址到已知代理列表，避免被视为非法请求
    // options.KnownProxies.Add(IPAddress.Parse("你的Front Door IP"));
});

// 原有的身份认证配置...
builder.Services
    .AddMicrosoftIdentityWebAppAuthentication(builder.Configuration)
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

// **移除手动设置redirectUri的OnRedirectToIdentityProvider事件代码**
builder.Services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
    options.SaveTokens = true;
    options.RefreshOnIssuerKeyNotFound = true;
    options.ClientId = azureConfig["ClientId"];
    options.ClientSecret = azureConfig["ClientSecret"];
    options.UseTokenLifetime = true;
    options.CallbackPath = azureConfig["CallbackPath"];
    // 删掉之前手动修改redirectUri的Events配置
});

// 其他服务配置...

var app = builder.Build();

// 在UseRouting之前启用Forwarded Headers
app.UseForwardedHeaders();

// 原有的管道配置...
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapRazorPages();

app.Run();

步骤2：配置应用注册的Redirect URI #

在Azure AD应用注册中，添加Front Door的完整回调地址，比如：
https://your-frontdoor-domain.com/signin-oidc
确保删除或保留原有的App Service地址（如果需要兼容直接访问的场景）。

步骤3：验证Front Door配置 #

确保Front Door已启用转发X-Forwarded-For和X-Forwarded-Proto头，这是ASP.NET Core识别原始请求地址的关键。

额外说明 #

• 此方案依赖反向代理传递的头信息，让应用自动生成与原始请求一致的redirect_uri，确保认证流程的所有环节（授权请求、回调、令牌获取）使用相同的地址，避免不匹配问题。
• 无需手动修改redirect_uri，减少出错概率，同时兼容开发环境（开发环境无代理，中间件自动使用本地地址）。

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