Impersonation (login as user)
A controlled support session that lets staff see the product as a user while preserving who the staff member really is.
What it is
Impersonation lets an authorized staff member enter the product with a user's view and permissions for support. A safe impersonation session keeps two identities: the subject being viewed and the staff actor who started it. It never asks for, resets, or learns the user's password.
Reach for it when screenshots and database inspection cannot reproduce a customer-specific problem. Require a narrowly assigned support role, step-up authentication, a ticket or reason, a short expiry, and a persistent banner with a one-click exit. Read-only mode is a strong default for most support work. Salesforce is the long-running example: Log in as any user is a separate administrator permission, and the session it opens is recorded.
The dangerous version erases the actor, making staff actions look as if the customer performed them. Record both people in every audit event, notify or expose the session to the customer according to policy, and block high-risk actions such as password changes, MFA changes, billing, exports, and creation of new credentials.
Ask AI for it
Implement support impersonation with a server-side session containing a subject user ID and a separate actor staff ID, matching the RFC 8693 act claim model. Require a support:impersonate permission, WebAuthn step-up, a ticket ID and reason, then issue a 15-minute non-renewable session. Show a fixed 'Viewing as' banner with the subject, actor, remaining time, and exit button on every page. Default to read-only and deny password, MFA, billing, export, token, and account-deletion routes on the server. Write start, action, and stop audit events with both identities, revoke the session on role removal, and never accept an impersonation target from an unsigned client cookie.