User impersonation, sometimes called “login as user”, lets a support engineer see a customer’s account exactly as the customer does, without asking for their password. In a multi-tenant SaaS product, signing in is the easy part. The harder questions are who may open which account, what they may do there, how access ends, and what record is left afterwards.
The rule of thumb behind every item below: treat support access as a separate, limited session, not a shortcut around your authorization. The staff member stays identifiable, while the app uses the customer’s permissions and tenant.
You can use this checklist to judge an in-house build, your auth provider’s built-in tools, or a product like Devora.
1. Keep the staff member separate from the customer
Every support session involves two people: the actor, who is investigating, and the subject, the impersonated user whose account they are in. A shared admin login erases that distinction. Signing in with the customer’s password is worse, because everything the agent does looks like the customer did it.
For any session you should be able to answer:
- Which staff member started it?
- Which customer user and tenant did they open?
- Which approved request allowed it?
- Which application credential belongs to this session?
Make the session obvious to the person using it, too. Devora’s React SDK includes an ImpersonationBanner for this (see the frontend guide (opens in a new tab)). Check that whatever banner you use shows up in every layout of your app.
Keep the customer’s own sessions separate. Ending an investigation shouldn’t log the customer out of every device. Check how your auth provider actually issues and revokes sessions before you assume each one can be revoked on its own.
2. Decide who may open which account, before issuing anything
Being allowed to request support access doesn’t mean being allowed to open every user in every workspace. Resolve the target on the server and check the staff member’s eligibility before you create a session.
For example, an agent assigned to Workspace A shouldn’t reach Workspace B by editing an ID in a request. That assignment rule is your application’s. So are decisions about inactive accounts, admin accounts and customers who have opted out of a support process.
Once the session exists, keep checking the customer’s tenant and resource permissions on every request. “May this agent open this account?” and “may this account see this record?” are different checks, and you need both. The assigned-customer guide goes into the first one in detail.
3. Make the approval policy explicit
Ask for a reason, the target account, the scope and the shortest useful duration. Devora’s request form offers 15 minutes to 2 days, with 15 minutes pre-selected. “Ticket 4821: export button missing for this user” is far more useful than “debugging”. Don’t paste sensitive ticket contents into the request.
In Devora, any organization member can request access. An approver or admin in your organization decides. Admins can approve their own requests by default, and that is always recorded as self-approved. If your policy requires a second person to approve, turn self-approval off in settings. An admin approving their own request isn’t independent review.
Internal approval and customer authorization are separate questions. A banner shown to staff isn’t notice to the customer, and an internal approval isn’t customer consent. Decide those policies on their own terms. In Devora, a customer approval step after internal approval is on the roadmap; until then, collect customer consent in your own process.
4. Enforce scope where requests are authorized
Disabling edit buttons stops honest mistakes. It doesn’t stop someone calling your API directly. Enforcement belongs in your backend, and in any other system that accepts the support session’s credential.
Devora’s backend guard checks the verified session context, scope, endpoint rules, expiry and whether the session is still live. Your developers install it on the routes that matter and keep your normal authentication and authorization in place. The guard filters by method and path, so it can’t tell that a particular GET sends an email. The scope and security guide (opens in a new tab) covers the details.
List the operations that send email, start jobs, create exports or change data, including ones that look like reads. Anything the browser reaches directly, such as a database or storage SDK, needs its own rules. Read-only user impersonation walks through this inventory.
Read-only also isn’t the same as minimal exposure. Decide separately which fields and records support should be able to see.
5. Treat expiry, termination and browser cleanup as different things
A status change in a dashboard, an expired handoff token and a revoked application session are not the same event.
The agent or an admin can end a Devora session early, and an admin can revoke the approval behind it. Give every support credential an expiry that your server enforces. Link it to the access session so your backend can revoke it when the session ends, including when the agent has already closed the tab. Clearing browser state and sending the agent to a safe page is good hygiene, but it can’t be your only way of ending access.
Devora sends your backend a signed termination notice whenever a session ends, and its backend guard checks whether a session is still live. Those checks are briefly cached and notices are delivered over the network, so test where access is actually cut off rather than promising instant logout everywhere. Your application still owns the credential it created. See the session lifecycle guide (opens in a new tab).
One subtlety: recording and activity data captured just before a session ends can arrive up to 60 seconds later and is still stored, except when the session ended because of a data erasure. That’s late delivery of data that already existed. It never gives the agent more time in the account.
6. Record access and business actions separately
An access record explains who asked for a session, who approved it, which account was opened, why, with what scope and for how long. A business audit event explains something that happened in your app, such as an export or a role change.
You probably need both. Devora’s access history isn’t a log of every action inside your application. When your app records an action, store both the staff member and the customer, and keep credentials and unnecessary personal data out of the log. The audit-log guide shows how.
7. Turn on recording deliberately
In Devora, session recording and activity capture are optional and off by default. Admin settings control what’s captured and how it’s masked for new sessions. Masking a recording isn’t the same as removing data from an API response, or limiting what an agent can see live.
Recordings can contain customer and third-party information, so decide what evidence an investigation really needs before turning capture on. Review notice, access and retention with the right people in your organization. The privacy and recording guide (opens in a new tab) explains the controls. It doesn’t replace your privacy policy.
Staging checklist
Use synthetic accounts and test data, and call the API directly where you can. The expected results are pass conditions to check, not results we’ve already run. The Devora testing guide (opens in a new tab) has the full list.
| Test | Expected result | Evidence to keep |
|---|---|---|
| Request access to an unassigned customer | No session is issued | The eligibility decision |
| Read a record from another tenant | Your app’s authorization rejects it | The request and denial reason |
| Send a write straight to the API in a read-only session | The backend rejects it | The API response, not just a disabled button |
| Call a read-looking route that starts a job | An explicit rule blocks the side effect | Job queue and data state |
| End access while an app page is still open | The next protected request is rejected | Termination time and that next request |
| Close the tab, then end access as an admin | Server-side revocation still works | Credential mapping and cleanup record |
| Perform an allowed diagnostic action | Records show staff member and customer separately | Access record and business event |
| Leave recording off | No recording exists for the session | Capture settings and session state |
Are your existing tools enough?
Your auth provider or an existing library may already cover most of this. Compare their whole workflow against the checklist before deciding you need another tool. Build vs buy user impersonation helps with that decision.
Devora adds a managed workflow around requests, approvals, scoped sessions and access history. The security page summarizes how it handles each stage. You still integrate user lookup, credential creation and revocation, frontend sign-in and backend enforcement. The provider matrix (opens in a new tab) shows which route fits your auth setup.
If that split of responsibilities works for your app, create a Devora account and run one staging support session against this checklist before giving anyone production access.