当会话是Bearer Token时的用户模拟：为何Cookie交换方案失效

在传统的Web应用架构中，用户模拟（Impersonation）是一个常见需求——管理员或客服人员需要临时以某个用户身份登录，以排查问题或提供支持。多数框架推荐的做法是「交换Cookie」，但当你的会话机制基于Bearer Token而非Cookie时，这套方案便不再适用。

Cookie交换方案为何无法迁移

绝大多数Web框架在讨论用户模拟时，默认前提是会话状态存储在Cookie中。管理员发起模拟时，系统会将当前会话Cookie替换为目标用户的会话Cookie，浏览器随后携带新Cookie发起请求，服务端据此识别出「被模拟的用户」。

这种模式的核心依赖在于：Cookie是由浏览器自动管理、随请求自动附带的凭证载体。整个交换过程发生在服务端与浏览器的隐式协作之中，开发者只需操作Set-Cookie响应头即可。

然而，当会话凭证是Bearer Token时，情况截然不同。Bearer Token通常存储在前端应用的内存或本地存储中，通过Authorization: Bearer <token>请求头显式传递。它不具备Cookie那种「浏览器自动附带」的特性，因此服务端单纯替换某个存储值的思路无从落地——你无法像操作Cookie那样，让浏览器在下一次请求中自动带上一个「被模拟身份」的凭证。

Bearer Token的存储位置选择本身也涉及安全权衡。存储在内存（JavaScript变量）中的Token在页面刷新后会丢失，安全性较高，因为XSS攻击无法通过document.cookie或localStorage读取它；但存储在localStorage中的Token可以在标签页关闭后持久存在，代价是暴露于XSS风险之下。无论哪种存储方式，Token都不会随请求自动附带——开发者必须在每次HTTP调用时显式地将其写入Authorization请求头，这与浏览器对Cookie的透明处理机制形成了根本性差异。这一「显式传递」特性，正是Cookie交换思路无法在Bearer Token架构下直接复用的底层原因。

不同SDK实际交给你的是什么

理解模拟机制的关键，在于弄清每个身份认证SDK在模拟场景下实际返回给你的是什么。这里存在明显的差异：

有些SDK返回的是一个全新的、代表被模拟用户身份的完整Token。这意味着后续所有请求都携带这个新Token，服务端将其视为目标用户的正常会话。

另一些SDK则返回带有特殊声明（claims）的Token，在标准的用户身份信息之外，额外嵌入「这是一次模拟会话」以及「实际操作者是谁」的元数据。这种设计保留了审计能力——服务端始终清楚真实操作者的身份，即便请求表面上以被模拟用户的名义发出。

这种差异直接影响你的实现策略。如果SDK只给你一个「纯净」的目标用户Token，你就失去了在后端追溯真实操作者的天然线索，需要自行在应用层维护映射关系；而如果Token携带了模拟声明，你则可以直接依赖Token本身完成权限校验与审计日志记录。选择或封装SDK时，明确这一点至关重要。

JWT（JSON Web Token）是Bearer Token最常见的具体实现形式，其Payload部分是一段Base64编码的JSON，可以携带任意自定义声明（claims）。在模拟场景中，SDK通常会在标准声明（如sub表示被模拟用户）之外，添加私有声明，例如act（actor）字段记录真实操作者的用户ID，或用impersonated: true标记此次会话性质。由于JWT是自包含的（self-contained），服务端无需额外查询数据库即可从Token本身提取这些信息，直接用于权限判断和审计日志写入。这也是「携带模拟声明的Token」相比「纯净目标用户Token」在可观测性上具有天然优势的技术原因。

为何Bearer Token的退出路径更安全

有意思的是，虽然Bearer Token让「进入」模拟状态变得更复杂，但它的「退出」路径反而比Cookie方案更安全。

在Cookie交换方案中，退出模拟意味着要把被模拟用户的Cookie换回管理员原本的Cookie。这里存在一个隐患：管理员的原始会话凭证必须在模拟期间被安全保存（通常暂存于服务端某处或另一个Cookie中），退出时再恢复。这个保存-恢复的过程本身就是攻击面——如果原始凭证泄露或恢复逻辑出错，可能导致会话混淆甚至权限提升。

Bearer Token的模型下，退出路径更为清晰。模拟Token通常是短时效、明确标记用途的独立凭证。结束模拟时，前端只需丢弃这个模拟Token、切回原本持有的管理员Token即可。管理员的原始凭证自始至终由前端持有，无需经历「暂存-恢复」的高风险流转。凭证边界更清晰，误用的可能性也随之降低。

实践中的建议

综合来看，当你的会话建立在Bearer Token之上时，用户模拟的实现应当围绕Token本身来设计，而不是套用Cookie时代的交换思路。

优先选择能够在模拟Token中嵌入「真实操作者」声明的方案，这既满足了功能需求，又内建了审计能力。同时，为模拟Token设置较短的有效期，并确保管理员的原始Token始终安全地保留在客户端，从而让退出模拟成为一个简单、低风险的操作。

理解你所使用的SDK在这一场景下的具体行为，是安全实现的第一步——不要假设它的模拟机制与文档中面向Cookie的通用建议一致。