适配遗留系统：咨询除Set-Cookie外的认证凭证HTTP响应头

针对你需要支持不兼容Set-Cookie/Cookie头的遗留系统，同时要避免自定义头缓存风险、简化令牌续期逻辑的需求，以下是几个可行的解决方案：

1. 带严格缓存控制的自定义响应头 #

• 实现方式：使用自定义头（如X-Auth-Token: TheToken）返回令牌，同时在响应中强制添加Cache-Control: no-store和Pragma: no-cache头，明确告知代理和客户端禁止缓存该响应内容。
• 优势：续期逻辑完全对标Set-Cookie——在用户任意请求的响应头中附带更新后的令牌，客户端只需监听该自定义头即可自动完成续期，无需额外复杂逻辑；通过缓存控制头彻底规避自定义头被代理缓存的安全风险。
• 注意事项：需确认遗留系统的HTTP客户端能够正确读取并解析自定义响应头。

2. 复用Authorization头进行令牌下发 #

• 实现方式：登录成功时，在响应头中返回Authorization: Bearer TheToken，客户端提取该头的值后，后续请求沿用Authorization头提交令牌（与你当前的客户端逻辑一致）。
• 优势：无需新增自定义头，Authorization头本身属于标准HTTP头，多数代理默认不会缓存携带该头的响应；配合Cache-Control: no-store进一步强化缓存安全，续期逻辑同样支持随任意请求返回更新后的令牌。

3. 响应体嵌入令牌+优化续期逻辑 #

• 实现方式：登录响应体中包含令牌及过期时间（如{"auth_token": "TheToken", "expire_ts": 1699999999}），客户端存储后按需使用。
• 续期优化：
  • 新增专门的POST /refresh-token端点，客户端在令牌临近过期时主动调用获取新令牌；
  • 或在所有请求的响应体中添加可选的new_auth_token字段，仅当令牌需续期时返回该字段，客户端检查到则更新本地存储。
• 优势：完全避开HTTP头的兼容性和缓存问题；劣势是续期逻辑相比头传输更繁琐，需要客户端主动处理过期判断。

方案优先级推荐 #

优先选择带严格缓存控制的自定义响应头方案，它既匹配你期望的"随任意请求续期"的简洁逻辑，又通过缓存控制头解决了自定义头的安全风险，同时对遗留系统的适配成本最低。

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