自定义DelegatingHandler内刷新JWT是否需要创建第二个HttpClient

问题结论 #

刷新令牌的请求不是必须使用第二个独立HttpClient，两种实现方式都有成熟的落地案例，你目前的独立HttpClient方案已经是合理可用的，也可以选择更精简的同实例方案。 #

同HttpClient实现的解决思路 #

你担心的循环引用问题本质是：主HttpClient的请求管道包含了当前的AuthenticationHandler，如果直接用主HttpClient发起刷新请求，刷新请求会再次进入当前Handler的认证、401重试逻辑，可能造成死循环。
要规避这个问题有两种简单的方案：

方案1：跳过刷新请求的认证逻辑 #

在你的AuthenticationHandler逻辑中增加分支判断：

• 在CheckForAuthToken方法中，检测如果当前请求路径是刷新令牌接口，就跳过向请求头添加普通JWT的逻辑
• 在401重试的判断分支前，检测如果当前请求是刷新令牌请求，直接跳过重试逻辑，避免刷新请求返回401时进入无限重试
  你可以将主HttpClient通过构造函数注入到AuthenticationHandler中，即可在Handler内部直接调用，不会出现循环问题。

方案2：直接调用底层Handler发请求，跳过自定义管道 #

不需要引入额外HttpClient，直接使用DelegatingHandler内置的InnerHandler发起刷新请求，InnerHandler是HttpClient管道的最终执行层，不会触发你自定义的认证逻辑，完美规避循环：

// 刷新令牌时直接用InnerHandler发起请求，不走当前AuthenticationHandler逻辑
var refreshRequest = new HttpRequestMessage(HttpMethod.Post, "/api/v1/auth/refresh")
{
    Content = JsonContent.Create(refreshTokenRequestModel)
};
var refreshResponse = await InnerHandler.SendAsync(refreshRequest, cancellationToken);

现有代码的优化建议 #

• 你当前的重试循环逻辑存在问题：for (int i = 1; i == _maxRefreshAttempts; i++)只有当_maxRefreshAttempts = 1时才会执行1次，建议修改为for (int i = 0; i < _maxRefreshAttempts; i++)匹配预期的重试次数
• 增加异步锁控制刷新请求：如果多个业务请求同时返回401，会同时发起多个刷新请求，可能导致刷新令牌提前失效，建议用SemaphoreSlim做异步锁，同一时间只允许一个刷新请求执行
• 增加刷新失败的退出逻辑：如果刷新请求返回401（代表刷新令牌也已过期），直接终止重试，抛出需重新登录的异常或返回原401响应，避免无意义的循环

方案选择建议 #

• 如果你的刷新接口和业务接口域名、配置完全一致，优先选择用InnerHandler发刷新请求的方案，代码最精简
• 如果刷新接口有独立的域名、超时、重试策略，或者你希望认证逻辑和业务逻辑完全隔离，保留当前的独立HttpClient方案即可，没有冗余问题，是生产环境非常常见的实现

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