Is user impersonation safe?

It can be, if it's controlled. Give each agent their own session instead of a shared login, require a reason and an approval, default to read-only access enforced by your backend, set a hard expiry, and keep a record of who opened which account. Password sharing and shared admin accounts are the unsafe versions, because nothing shows who acted.

What's the difference between impersonation and sharing a password?

Sharing a password hands over the customer's own login. Everything then looks like the customer did it, MFA gets in the way or is switched off, and the customer has to change the password afterwards. Impersonation gives the agent a separate session that never touches the customer's password, can be limited and ended on its own, and records the agent as the person acting.

How do I log in as another user in my app?

Check your auth provider first: Clerk, Auth0, WorkOS and Better Auth each have a native way to sign in as a user. With your own auth, have your backend issue a short-lived credential for the target user that also carries the staff member's identity, and enforce scope and expiry on every request. Add approval and access history once more than a few trusted people need it.

What is an impersonated user?

The impersonated user is the account being accessed, also called the subject. The person doing the accessing is the impersonator, or actor. A well-built system keeps both in its tokens and logs, so an action reads as 'this agent, acting in this user's account' rather than as the user's own.

Does the customer know when support logs in as them?

Not unless you tell them. Devora, for example, sends nothing to the customer and doesn't touch their own login. Its approvals are internal today, and a step that sends the request to the customer after internal approval is on the roadmap. Decide your own notice policy and put it in your terms or support process.

What Is User Impersonation? Why Teams Log In as User

User impersonation is when an authorized staff member signs in to your application as a specific user, without that user’s password, to see and use the product exactly as that user does. Done safely, it’s a separate, time-limited session that keeps the staff member’s own identity on record, so anything that happens can be traced to them and not to the customer.

Teams call it many things: “log in as user”, “login as customer”, “impersonate user” or “switch user”. The staff member is the impersonator, and the account they enter is the impersonated user. The idea isn’t unique to SaaS support. Kubernetes describes user impersonation (opens in a new tab) as letting an authenticated user act as another user, and Symfony’s impersonation guide (opens in a new tab) gives the classic reason: debugging something a user sees that you can’t reproduce.

This guide covers how impersonation works, why teams rely on it, what goes wrong, and how to do it without the shortcuts that make it risky. If you already know the basics, the safe impersonation checklist for multi-tenant SaaS goes deeper on the controls.

What does impersonating a user look like?

Impersonating a user means you see their screens, their data and their permissions, because the app treats you as them for the length of the session. Here’s an illustrative scenario, not a real customer.

A customer admin writes in: the Export button has disappeared for everyone on their team. In the agent’s own test account, the button is there. The logs show no errors, and the customer’s role looks the same as one that works.

The agent requests read-only access to one affected user for 30 minutes, with the ticket as the reason. A teammate approves. The agent opens the app as that user, with a banner reminding them whose account they’re in. Within a few minutes the cause is visible: the workspace sits on an old billing tier, and a feature flag hides Export for that tier. The agent ends the session, notes the flag and the tier, and hands both to engineering. Nothing in the customer’s account changed.

Logs and screenshots hadn’t shown that combination. Seeing the account as the user saw it did.

How does user impersonation work?

User impersonation works by creating a new session in which your application treats the staff member as the customer user, while separately recording who the staff member really is. Five ideas cover most of it.

Actor and subject. The actor is the person doing the work, such as a support agent. The subject is the user whose account and permissions are used. The OAuth token exchange standard, RFC 8693, defines impersonation (opens in a new tab) as one party being given another’s rights and becoming indistinguishable from them in that context. Good support tools don’t let the actor disappear. Tokens can name the agent in an act (actor) claim (opens in a new tab), or your server can keep it in session data. Impersonation vs delegation explains how these models differ.

A separate session. The agent gets their own session in the customer’s account. The customer’s password isn’t used, and their own login is left alone.

Scope. A read-only session lets the agent look without changing anything. A read-write session lets them make ordinary changes, such as finishing setup the customer asked for. Either way, some actions, like changing the password or billing details, should stay blocked. Read-only only holds if your backend enforces it, and read-only user impersonation covers what to block.

Expiry. Every session needs a time limit that the server enforces, so access ends even if nobody remembers to end it.

Ending. Ending a session means your server stops accepting its credential, not just that someone clicked a button in a tab. Impersonation session termination covers expiry, revocation and tabs left open.

Why do SaaS teams log in as users?

Teams log in as users because many problems only show up in one account, under one user’s permissions, data and settings. The common reasons:

Permission bugs. A button is missing or a page returns 403 for one user, and the cause is a role, grant or entitlement you can only see from their side. Work through the evidence in debugging customer permission issues first. Impersonation is the step for when that runs out.
Data and configuration issues. An import stopped halfway, an integration is misconfigured, or a report shows the wrong totals because of one record.
Onboarding help. A customer asks support to finish setting up their workspace. That needs write access and a clear approval, because the agent will change real data.
Verifying fixes. After a fix ships, an agent confirms the customer’s view is correct before replying “it’s fixed”.

Each of these goes faster when the agent sees exactly what the user sees, instead of piecing it together from screenshots and guesses.

What are the risks of user impersonation?

The risk of user impersonation is that someone outside the customer gets the customer’s access, often with nothing to show who it was or why. Most problems come from shortcuts:

Asking for the customer’s password. It gets in the way of MFA, so the customer passes on codes or switches it off. Every action looks like the customer’s, and they should change the password afterwards.
Shared admin logins. A superuser account used by the whole team can open any account, and the logs only ever say “admin”.
No audit trail. If your logs record only the token’s user, actions an agent takes appear as the customer’s own. Audit logs for user impersonation shows how to record both people.
Access that’s too broad or never ends. A “log in as any user” button available to every agent is standing access to every customer’s data. A session without a hard expiry stays usable long after the ticket closes.
Side effects. Even looking can change things: last-seen timestamps, read receipts, analytics events, onboarding emails or webhooks triggered by a page load.
Mixed-up sessions. If the impersonated session replaces the agent’s own, or carries over into another tab, agents can act in the wrong account without noticing.

None of these is a reason to avoid impersonation. They’re reasons to build it with controls.

Safe vs unsafe ways to log in as a user

The safe way to log in as a user is a separate session tied to both the agent and the customer, approved for a stated reason, limited in scope and time, and enforced by your backend. Here’s how the usual options compare.

Method	How it works	Main problem	Verdict
Asking for the customer’s password	The agent signs in with the customer’s credentials	Clashes with MFA, no record of who acted, customer must change the password	Unsafe
Resetting the customer’s password	The agent sets a new password and signs in	Locks the customer out and hides who acted	Unsafe
Shared admin or superuser account	The team shares one powerful login	No individual accountability; reaches every account	Unsafe
Homegrown “log in as” button with no controls	Any staff member can open any account	Standing access, often no expiry or actor record	Risky
Your auth provider’s native impersonation	The provider signs the agent in as the user and records the actor	Handles sign-in; approval, scope and ending are mostly yours	Fine for small, trusted teams
Approved, scoped, time-limited impersonation	Request, approval, read-only by default, server-enforced expiry and termination, access history	More parts to set up	Safe default for support teams
Screen sharing or co-browsing	The customer shows you their screen or shares the page	The customer must be there; you see only what they show	Safe alternative when the customer is available

What do auth providers offer natively?

Most major auth providers already let you log in as a user, so you may not need to build the sign-in part yourself.

Provider	Native feature	How your app sees the agent
Clerk	Impersonation from the dashboard, or actor tokens through the Backend API	`act` claim on the session token
Auth0	Session Delegation, built on Custom Token Exchange	`act` claim on the ID and access tokens
WorkOS AuthKit	Impersonation from the WorkOS Dashboard, with a required reason	`act` claim with the impersonator’s email
Better Auth	Admin plugin `impersonateUser` and `stopImpersonating`	`impersonatedBy` field on the session

A few details worth knowing:

Clerk’s impersonation docs (opens in a new tab) describe impersonating from the Users page and creating actor tokens, whose actor ends up in the session token’s act claim. Clerk user impersonation for support has a worked example.
Auth0 launched Session Delegation in Open Early Access (opens in a new tab) on August 7, 2026. Auth0’s Session Delegation docs (opens in a new tab) say it lets an authorized actor, such as a support agent, establish a web session as another user, and records the delegation in tenant logs. It issues no refresh tokens and fails if MFA or consent would be required. Auth0 user impersonation options compares it with the alternatives.
WorkOS impersonation (opens in a new tab) is off by default, asks for a reason that it records on the session.created event, and ends sessions after 60 minutes.
Better Auth’s admin plugin (opens in a new tab) keeps an impersonation session for up to an hour by default, and doesn’t let admins impersonate other admins unless you grant that permission.

These features handle the sign-in. They generally leave the rest to you: which agent may open which customer, approval, read-only enforcement in your API, ending access when a ticket closes, and a review trail across the team. Whether to build that layer or buy it is a separate decision, covered in build vs buy user impersonation.

When shouldn’t you impersonate a user?

Don’t impersonate a user when something less invasive answers the question. Opening a customer’s account means seeing their data, so treat it as a later step, not the first one.

Logs and traces often explain an error faster, without showing anyone’s data.
Session replay shows what happened in a past visit, if you already capture it.
A support view, meaning a read-only admin page showing an account’s plan, flags, roles and integration status, answers many tickets without opening the account.
A staging copy with synthetic data lets engineering reproduce a bug and test the fix safely.
Screen sharing or co-browsing suits problems in the customer’s own browser or device, when they’re free to show you. Co-browsing vs screen sharing vs user impersonation compares the three.

Some tasks need the customer themselves: changing a password or MFA, accepting terms, or adding a payment method. Don’t do those through impersonation at all.

How Devora handles user impersonation

Devora adds the workflow around the sign-in: requests, approvals, scope, time limits, termination and access history. Your auth provider still creates the session.

Request. A team member picks the customer from search results your application supplies (opens in a new tab), then asks for read or write scope, a duration and a reason. Durations run from 15 minutes to 2 days, with 15 minutes pre-selected.
Approval. An admin, or an approver in your organization, reviews the request. Devora’s overview for teams (opens in a new tab) notes that admins can approve their own requests unless you turn that off, and Devora records self-approval separately.
Session. Your backend creates a short-lived credential for the customer user, and the agent works in your app with a visible banner. The customer’s password isn’t involved.
Scope. Read sessions allow GET, HEAD and OPTIONS and block other methods unless you add a reviewed exception. Write sessions allow ordinary changes. “Always blocked” rules you set, for example on password, billing, API key and role endpoints, apply to both. Devora’s backend scope guard (opens in a new tab) enforces this on the routes you protect and fails closed when it has no policy.
Ending. A session ends when the agent ends it, an admin terminates it or revokes the approval, or it reaches its time limit or idle timeout. Devora then sends your backend a signed termination request, retried if delivery fails, even when no tab is open. Session lifecycle and cleanup (opens in a new tab) lists every reason.
Access history. Devora keeps the requester, target, reason, scope, decisions, timing and termination. Devora’s security page is clear that this is access history, not a record of every action inside your app. Session recording is optional (opens in a new tab) and off by default.

Today, Devora’s approvals are internal: an admin or approver in your organization decides, and Devora sends the customer nothing. A step where the request goes to the customer after internal approval, with the session starting once the customer approves, is on the roadmap. Until then, your organization decides when to tell customers about staff access.

Your application still owns authentication, issuing and revoking the credential, tenant authorization and business audit events. The auth provider matrix (opens in a new tab) shows the routes: Clerk is supported, Better Auth works with a binding route you write, Auth0 uses an advanced Custom Token Exchange route, WorkOS has a limited app-owned bridge, and custom auth uses a one-time session bridge.

If your team logs in as users today through a shared account or a bare button, create a Devora account and try one staging session. Request read-only access to a test user, end the session from the dashboard, and check that your backend refuses the next request.

What is user impersonation? Why SaaS teams 'log in as user'