User Impersonation When Sessions Are Bearer Tokens: Why the Cookie-Swap Approach Fails

In traditional web application architecture, user impersonation is a common requirement — administrators or support staff need to temporarily act as a specific user to troubleshoot issues or provide assistance. Most frameworks recommend a "cookie swap" approach, but when your session mechanism is based on Bearer Tokens rather than cookies, that solution simply doesn't apply.

Why the Cookie-Swap Approach Doesn't Translate

When most web frameworks discuss user impersonation, they implicitly assume that session state is stored in cookies. When an admin initiates impersonation, the system replaces the current session cookie with the target user's session cookie. The browser then attaches the new cookie to subsequent requests, and the server identifies the "impersonated user" accordingly.

The core dependency of this pattern is that cookies are automatically managed by the browser and attached to every request. The entire swap happens through implicit collaboration between the server and the browser — developers only need to manipulate the Set-Cookie response header.

With Bearer Tokens, however, the situation is fundamentally different. Bearer Tokens are typically stored in the frontend application's memory or local storage and passed explicitly via the Authorization: Bearer <token> request header. They don't have the "automatically attached by the browser" characteristic of cookies, so the server-side approach of simply replacing a stored value doesn't work — you can't instruct the browser to automatically carry an "impersonated identity" credential on the next request the way you can with cookies.

The choice of where to store Bearer Tokens also involves security tradeoffs. Tokens stored in memory (JavaScript variables) are lost on page refresh and offer higher security, since XSS attacks can't read them via document.cookie or localStorage. Tokens stored in localStorage can persist after a tab is closed, but at the cost of exposure to XSS risks. Regardless of storage location, tokens are never automatically attached to requests — developers must explicitly write them into the Authorization header on every HTTP call. This is a fundamental difference from the browser's transparent handling of cookies, and it's precisely why the cookie-swap mental model can't be directly reused in a Bearer Token architecture.

What Different SDKs Actually Give You

The key to understanding impersonation mechanics is knowing what each identity SDK actually returns to you in an impersonation scenario. There are meaningful differences here.

Some SDKs return a completely new token representing the impersonated user's identity. This means all subsequent requests carry this new token, and the server treats it as the target user's normal session.

Other SDKs return tokens with special claims — metadata embedded alongside the standard user identity information indicating that "this is an impersonation session" and "the actual actor is this person." This design preserves auditability — the server always knows the real operator's identity, even when requests are nominally made on behalf of the impersonated user.

This difference directly affects your implementation strategy. If the SDK only gives you a "clean" target-user token, you lose the natural thread for tracing the real actor on the backend and must maintain that mapping yourself at the application layer. If the token carries impersonation claims, you can rely on the token itself for authorization checks and audit log recording. When choosing or wrapping an SDK, understanding this distinction is critical.

JWT (JSON Web Token) is the most common concrete implementation of Bearer Tokens. Its payload is a Base64-encoded JSON blob that can carry arbitrary custom claims. In impersonation scenarios, SDKs typically add private claims beyond the standard ones (e.g., sub for the impersonated user) — for example, an act (actor) field recording the real operator's user ID, or an impersonated: true flag marking the nature of the session. Because JWTs are self-contained, the server can extract this information directly from the token without an additional database query, using it immediately for authorization decisions and audit logging. This is the technical reason why "tokens carrying impersonation claims" have a natural observability advantage over "clean target-user tokens."

Why Bearer Token Exit Paths Are Actually Safer

Interestingly, while Bearer Tokens make "entering" an impersonation state more complex, the "exit" path is actually safer than the cookie-based approach.

In the cookie-swap model, ending impersonation means swapping the impersonated user's cookie back to the admin's original cookie. There's a latent risk here: the admin's original session credential must be safely preserved during the impersonation period (typically temporarily held server-side or in another cookie), then restored on exit. This save-and-restore process is itself an attack surface — if the original credential leaks or the restoration logic fails, it could lead to session confusion or even privilege escalation.

Under the Bearer Token model, the exit path is much cleaner. Impersonation tokens are typically short-lived, purpose-marked, standalone credentials. To end impersonation, the frontend simply discards the impersonation token and switches back to the admin token it already holds. The admin's original credential remains with the frontend throughout — it never goes through a high-risk "store and restore" cycle. Credential boundaries are cleaner, and the potential for misuse decreases accordingly.

Practical Recommendations

Taken together, when your sessions are built on Bearer Tokens, implementing user impersonation should be designed around the tokens themselves — not by adapting the cookie-era swap approach.

Prioritize solutions that can embed "real actor" claims in the impersonation token. This satisfies the functional requirement while building in auditability by design. Additionally, set short expiration times on impersonation tokens, and ensure the admin's original token remains safely held on the client side at all times — making the exit from impersonation a simple, low-risk operation.

Understanding how your specific SDK behaves in this scenario is the first step toward a secure implementation — don't assume its impersonation mechanism aligns with the general cookie-oriented guidance in the documentation.