Impersonation when your session is a bearer token
Blog post from WorkOS
User impersonation in token-based AuthKit applications differs from traditional cookie-session approaches because impersonation identity is embedded in signed credentials through an impersonator object and the access token’s act claim, allowing APIs to verify both the acting user and the administrator responsible. Successful setup requires configuring the WorkOS Initiate login URI to the application’s sign-in route so PKCE validation can proceed correctly after the dashboard redirect. AuthKit React exposes impersonator state directly, while AuthKit JS requires developers to retain it from both redirect and token-refresh callbacks, and mobile SDKs return it through the public PKCE authentication response. Client-side claim decoding is suitable only for display features such as an impersonation banner, while authorization and auditing must rely on server-side token verification. The recommended exit design keeps the administrator’s and impersonated user’s tokens separate, making termination a matter of discarding the impersonation token rather than restoring a client-stored identity, avoiding vulnerabilities common in cookie-based implementations. Impersonation sessions expire after 60 minutes, with browser logout used for voluntary session ending and the server-side revoke API used to terminate sessions remotely.
No tracked trend matches for this post yet.
Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.