如何基于HttpClient处理非OAuth2规范的自定义令牌认证？

整体逻辑拆分为三个解耦的模块实现，完全匹配你描述的调用流程，不需要依赖OAuth2相关的客户端库：

核心模块实现 #

1. 线程安全的令牌缓存服务 #

这是实现本地令牌缓存的基础，作为单例服务全局共享，不做每个请求的独立存储：

• 内部存储三个核心字段：当前有效令牌字符串、令牌过期的UTC时间戳、最近一次令牌刷新的时间
• 暴露两个核心方法：
  • TryGetValidToken()：判断当前时间距离缓存的过期时间有预留冗余（通常提前3-5秒判定失效，避免临界值请求拿过期令牌），有效则返回缓存令牌，无效返回空值
  • UpdateCache(string newToken, DateTime expireTime)：收到新令牌后覆盖旧缓存，同步更新过期时间

2. 带单飞机制的令牌刷新逻辑 #

对应「令牌过期时仅单次发起获取请求、阻塞其他并发请求等待新令牌」的要求，使用SemaphoreSlim实现异步友好的单飞锁，避免多请求并发重复调用/auth接口：

// 初始信号量容量1，最大容量1，实现单飞阻塞
private readonly SemaphoreSlim _refreshSemaphore = new(1, 1);
private readonly TokenCache _tokenCache;
private readonly HttpClient _authClient; // 专门用来调/auth的客户端，不走自定义认证管道

public async Task<string> GetOrRefreshTokenAsync(CancellationToken ct)
{
    // 第一次前置检查：有有效令牌直接返回，不走锁
    var cachedToken = _tokenCache.TryGetValidToken();
    if (!string.IsNullOrEmpty(cachedToken)) return cachedToken;

    // 没有有效令牌，等待获取锁
    await _refreshSemaphore.WaitAsync(ct);
    try
    {
        // 拿到锁之后必须二次检查缓存！
        // 目的是覆盖「等待锁期间已经有其他请求完成了令牌刷新」的场景，避免重复调用/auth
        cachedToken = _tokenCache.TryGetValidToken();
        if (!string.IsNullOrEmpty(cachedToken)) return cachedToken;

        // 实际发起/auth请求获取新令牌
        var authResp = await _authClient.PostAsync("/auth", null, ct);
        authResp.EnsureSuccessStatusCode();
        var newToken = await authResp.Content.ReadAsStringAsync(ct);
        // 把新令牌写入缓存，设置匹配接口规则的过期时间
        _tokenCache.UpdateCache(newToken, DateTime.UtcNow.AddMinutes(30));
        return newToken;
    }
    finally
    {
        // 无论成功失败，都释放锁让其他等待的请求进入检查流程
        _refreshSemaphore.Release();
    }
}

单飞逻辑的效果：当令牌过期触发刷新时，所有并发发起的业务请求会全部阻塞在信号量上，只有第一个进入临界区的请求会实际调用/auth接口；等新令牌写入缓存、锁释放后，所有等待的请求会通过二次缓存检查拿到新令牌，直接恢复执行，全程只有一次/auth请求调用。
注意：拿锁后的二次缓存检查是单飞机制的核心，少了这一步会导致所有等待锁的请求进入临界区后重复调用/auth接口，完全不符合单次刷新的要求

3. 自定义HttpClient管道处理器 #

对应「将令牌存入Cookie发起资源请求」的要求，通过继承DelegatingHandler把认证逻辑嵌入HttpClient的请求管道，业务代码完全不需要手动处理Cookie注入、重试逻辑：

public class CustomCookieAuthHandler : DelegatingHandler
{
    private readonly TokenRefreshService _tokenService;

    public CustomCookieAuthHandler(TokenRefreshService tokenService)
    {
        _tokenService = tokenService;
        // 配置底层处理器，自动处理Cookie容器
        InnerHandler = new HttpClientHandler();
    }

    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken ct)
    {
        // 发请求前自动拿有效令牌，注入Cookie头
        var token = await _tokenService.GetOrRefreshTokenAsync(ct);
        request.Headers.TryAddWithoutValidation("Cookie", $"access_token={token}");
        
        var response = await base.SendAsync(request, ct);
        
        // 捕获接口返回401的提前失效场景：清旧缓存，刷一次新令牌后重试请求
        if (response.StatusCode == HttpStatusCode.Unauthorized)
        {
            _tokenService.ClearExpiredCache();
            token = await _tokenService.GetOrRefreshTokenAsync(ct);
            // 替换请求里的旧Cookie为新令牌
            request.Headers.Remove("Cookie");
            request.Headers.TryAddWithoutValidation("Cookie", $"access_token={token}");
            // 重新发起请求
            response = await base.SendAsync(request, ct);
        }
        return response;
    }
}

流程匹配校验 #

把实现逻辑和你描述的流程逐点对齐，无遗漏：

• 应用请求/auth接口获取令牌：由TokenRefreshService内部的/auth调用逻辑实现
• 应用在本地缓存令牌：由单例的TokenCache全局存储实现
• 应用将令牌存入Cookie中发起资源请求：由CustomCookieAuthHandler在管道层自动注入Cookie头，业务代码无感知
• 令牌过期：通过缓存的过期时间预判 + 接口返回401两种场景共同捕获
• 应用阻塞所有其他请求，仅单次发起新令牌的获取请求：由SemaphoreSlim单飞锁实现
• 所有等待中的请求将使用新令牌恢复执行：所有等待的请求在锁释放后通过二次缓存检查拿到新令牌，直接发起业务请求

落地注意点 #

• 专门调用/auth接口的HttpClient不能注册CustomCookieAuthHandler管道，避免递归触发认证逻辑
• 不要用普通的lock关键字包裹异步刷新逻辑，容易造成死锁，必须用支持异步等待的SemaphoreSlim
• 令牌缓存的有效期要预留3-5秒的冗余，避免刚好在临界点拿过期令牌触发不必要的401重试
• 令牌刷新的失败场景要做好异常向上抛出的处理，不要一直占着锁导致所有请求永久阻塞

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