通过HTTP Client发送JWT Token的正确方式及空Token问题排查

1. 当前实现方案是否合理？ #

当前通过DelegatingHandler拦截HttpClient请求并自动添加JWT Token的方案是合理的，完全符合.NET生态的最佳实践。这种方式的优势很明显：

• 逻辑封装：Token添加逻辑被集中在独立的Handler里，不用在每个HttpClient调用处重复写冗余代码
• 复用性强：所有注册了该Handler的HttpClient都会自动带上Token，无需逐个配置
• 符合管道设计：利用HttpClient的消息处理管道机制，扩展逻辑清晰易懂

需要注意的是，你把TokenHandler注册为Transient是正确的——因为DelegatingHandler不能是单例，否则依赖的IHttpContextAccessor无法正确获取当前请求上下文。

2. 是否有更直接的方式通过HttpClient发送Token？ #

有几种更简洁的替代方案，根据场景选择：

方案一：注册HttpClient时直接配置请求头 #

如果Token来源固定（比如从当前请求上下文获取），可以在注册HttpClient时直接注入IHttpContextAccessor并配置默认请求头：

stitchingServices.ForEach(x => services.AddHttpClient(x.Name, (sp, client) =>
{
    client.BaseAddress = new Uri(x.GraphqlUrl);
    var httpContext = sp.GetRequiredService<IHttpContextAccessor>().HttpContext;
    var accessToken = httpContext.GetTokenAsync("access_token").Result;
    if (!string.IsNullOrEmpty(accessToken))
    {
        client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
    }
}));

注意：这里用.Result是因为ConfigureHttpClient的委托是同步的，如果需要异步获取Token，还是推荐用DelegatingHandler的方式。

方案二：用匿名委托简化Handler（.NET 6+） #

如果不想单独写TokenHandler类，可以用匿名委托快速实现：

services.AddHttpClient(x.Name, client =>
{
    client.BaseAddress = new Uri(x.GraphqlUrl);
}).AddHttpMessageHandler(sp =>
{
    var accessor = sp.GetRequiredService<IHttpContextAccessor>();
    return new DelegatingHandler
    {
        InnerHandler = new HttpClientHandler()
    }
    {
        SendAsync = async (request, cancellationToken) =>
        {
            var accessToken = await accessor.HttpContext.GetTokenAsync("access_token");
            if (!string.IsNullOrEmpty(accessToken))
            {
                request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
            }
            return await base.SendAsync(request, cancellationToken);
        }
    };
});

不过这种方式可读性不如单独的Handler类，适合简单场景。

方案三：用标准化Token获取服务（IdentityServer/Azure AD场景） #

如果你的项目用了IdentityServer4或Microsoft Identity（Azure AD），可以直接用ITokenAcquisition服务获取Token，这种方式会自动处理Token刷新、缓存，比手动从HttpContext获取更可靠：

public class TokenHandler : DelegatingHandler
{
    private readonly ITokenAcquisition _tokenAcquisition;
    private readonly IConfiguration _configuration;

    public TokenHandler(ITokenAcquisition tokenAcquisition, IConfiguration configuration)
    {
        _tokenAcquisition = tokenAcquisition;
        _configuration = configuration;
    }

    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var scope = _configuration["ApiClientAuth:Scope"];
        var accessToken = await _tokenAcquisition.GetAccessTokenForUserAsync(new[] { scope });
        request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
        return await base.SendAsync(request, cancellationToken);
    }
}

3. 调试时access_token为null的解决方法 #

出现这个问题通常是以下几个原因，逐一排查：

• 未注册IHttpContextAccessor：
  .NET Core默认不会自动注册IHttpContextAccessor，必须在ConfigureServices中手动添加：

  services.AddHttpContextAccessor();
  

  这是最常见的原因，你的代码里没显示注册，导致accessor.HttpContext可能为null。

• SaveToken未开启：
  检查JwtBearer配置里的options.SaveToken = true;是否正确设置——只有开启这个选项，Token才会被保存到HttpContext中，供GetTokenAsync获取。

• 当前请求未经过认证：
  如果调用HttpClient的代码是在未认证的上下文（比如后台任务、定时任务）中，HttpContext.User是匿名的，自然拿不到Token。这种情况要改用客户端凭证模式获取Token，而不是从当前用户上下文拿。

• Token名称错误：
  确认GetTokenAsync("access_token")里的名称是否正确，部分认证方案可能用id_token或其他名称。可以用以下代码查看所有可用Token：

  var tokens = await accessor.HttpContext.GetTokensAsync();
  foreach(var token in tokens)
  {
      Console.WriteLine($"{token.Key}: {token.Value}");
  }
  

  找到正确的Token名称替换即可。

• 认证中间件顺序错误：
  确保app.UseAuthentication()在app.UseAuthorization()之前执行，并且放在app.UseEndpoints()等中间件前面，否则HttpContext里不会包含认证信息。

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