# User impersonation with actor tokens
## Minting
1. This is backend-only. From your server, call the actor tokens endpoint
with the subject user id, a short expiry in seconds, and the actor
object containing the impersonator's user id as sub.
2. The response includes a url attribute: a Frontend API URL that signs out
any existing session and prepares the sign-in for impersonation. Visit
it (or redirect the staff member to it) to consume the token.
3. Keep expiry short, ten minutes is the documented example shape. You can
revoke a token at any time through the revoke endpoint even before it
expires; revoked tokens can no longer sign anyone in.
## Detecting an impersonated session
1. Once signed in as another user, the session token carries an act claim
with the actor info (impersonator user id, impersonated session id).
2. Read the act claim in your backend on every request and branch: show a
persistent "you are impersonating X" banner, disable destructive
actions (password change, billing changes, data deletion) during
impersonated sessions, and tag audit log entries with both ids.
3. Do not rely on the UI alone. Any server mutation that matters must check
the act claim itself.
## Checklist
- Only staff with an explicit support role can mint actor tokens. The
minting endpoint lives behind your own admin authorization, not just
behind Clerk auth.
- Log every impersonation: who, whom, when, and what they did. This log is
the difference between a support tool and a liability.
- Actor tokens are one-time sign-ins. They are not a way to share accounts
and not a substitute for proper admin tooling.