Auth0 user impersonation: Session Delegation and support access options

Auth0 does support user impersonation today, but not through the feature most forum answers describe. The original impersonation endpoint (POST /users/{user_id}/impersonate) is filed under Legacy in Auth0’s API docs (opens in a new tab) and is deprecated, as the Auth0.NET SDK reference notes (opens in a new tab). That’s why older threads say Auth0 has no way to log in as another user. Since August 7, 2026, Auth0 has offered Session Delegation in Open Early Access, according to Auth0’s changelog (opens in a new tab). Auth0’s Session Delegation docs (opens in a new tab) say it lets an authorized actor establish an audited web session on behalf of another user.

So the real question isn’t whether Auth0 can do it. It’s which session model fits your support process: native Session Delegation, a Custom Token Exchange you design yourself, or an application-owned support session. This guide compares them.

How Session Delegation works

Auth0 describes Session Delegation (opens in a new tab) as a two-step flow:

1. Issue a Session Transfer Token. Your admin tool calls /oauth/token with a Custom Token Exchange request whose audience is urn:{tenant}:session_transfer. An Action decides whether the delegation is allowed, sets the target user (typically with setUserByConnection()) and calls setActor(). Recording the actor is mandatory.
2. Redeem it in the browser. The token is redeemed through the Authorization Code flow. The resulting tokens carry an act claim identifying the delegation.

Auth0 lists the feature for B2C Professional, B2B Professional and Enterprise plans. Check your own tenant before you design around it.

Session Delegation limits to plan around

Auth0’s behavior and monitoring page (opens in a new tab) lists constraints you can’t configure away:

Behavior	What it means for support
Authorization Code flow only	No implicit, SAML or WS-Federation redemption
Two-hour absolute and idle timeouts, hard-coded	A delegated session can’t be extended for a long investigation
Access token also expires at two hours	Plan API calls within that window
No refresh tokens (offline_access excluded)	Background jobs can’t keep working as the user
IP-based device binding always on	The session is tied to the agent’s IP; it can’t be relaxed or switched to ASN
Existing Auth0 session in the browser blocks it	The agent sees an error asking them to log out first; use a clean browser profile
Interactive prompts fail with interaction_required	MFA, consent or enrollment prompts can’t be completed during delegation
One level of actor only	Chained delegation isn’t supported

Troubleshooting redemption errors. First work out which step failed: issuing the Session Transfer Token (the exchange Action rejected it) or redeeming it in the browser. Auth0 logs dedicated delegation event types (opens in a new tab) for success and failure, each including the actor’s sub. For interaction_required, look at which prompt the target user’s login triggers, and don’t weaken the customer’s MFA policy to get past it. For the “log out first” error, the agent’s browser already has an Auth0 session.

Custom Token Exchange is a building block, not a workflow

Custom Token Exchange (CTE) lets your application send Auth0 a token it issued and have an Action validate it and choose the user. Auth0’s Custom Token Exchange docs (opens in a new tab) are explicit that validating the incoming token is your job. Weak validation can allow spoofing or replay attacks that let someone authenticate as another user. CTE has the same plan availability as Session Delegation.

Session Delegation uses CTE internally, but they aren’t interchangeable. With your own CTE flow you decide:

• Who may request access, and to which users.
• What credential results, where it is stored and what your backend trusts.
• How that credential is revoked when access should end.

A user ID from the browser is never enough to approve a delegation. The Action should only accept a token your backend signed after it checked the staff member and target.

What Devora documents for Auth0

Devora’s auth provider overview (opens in a new tab) and Auth0 guide (opens in a new tab) describe its Auth0 support as an advanced route, not a native Session Delegation integration. It works like this:

1. Your backend creates a short-lived (two-minute), signed subject token from Devora’s verified context, with a unique jti.
2. Your backend exchanges it through CTE. Your Action validates signature, issuer, audience, expiry and one-time use.
3. The resulting credentials go into an encrypted, HTTP-only application session that your app owns. That session carries Devora’s context unchanged and expires no later than the approved window.
4. Devora’s backend guard enforces scope and expiry on each protected request, and your app revokes the session when Devora ends access.

This gives you Devora’s request, approval, scope and access-history workflow, but you own an extra session layer. Devora has not integrated or tested native Session Delegation. Read the Auth0 guide (opens in a new tab) and the custom session bridge (opens in a new tab) before deciding.

Auth0 impersonation alternatives compared

Option	Session boundary	Choose it when
Native Session Delegation	Auth0 delegated web session (2-hour limit)	Your plan includes it and its fixed limits fit your support policy
Devora’s Auth0 route	Application session after CTE	You want approvals, scoped access and access history, and can own the session layer
Your own CTE or session bridge	Whatever your application creates and revokes	You need full control and will maintain the workflow yourself
Narrow support view or staging fixture	No customer login at all	The ticket can be answered from configuration or logs

The last row is often the right answer. For an entitlement question, an internal view of the account’s plan and roles may be enough. For something that happened last week, start with the evidence covered in when session replay isn’t enough. Current-account access shows how the account behaves now. It doesn’t recreate what happened then.

Check before you build

Whichever option you choose, confirm in a staging tenant that:

• An unauthorized staff member or an ineligible target can’t start access.
• Changing the requested organization can’t cross the customer’s tenant boundary.
• Protected requests can tell the staff actor and the customer apart.
• A reused or expired handoff token is rejected, with no usable partial session left behind.
• Blocked operations fail at the backend, including direct API calls.
• Ending access rejects the next protected request from a page that’s still open.
• Your application audit events record the staff actor, not just the customer.

Pair this with the multi-tenant impersonation checklist and the Devora testing guide (opens in a new tab). Native Session Delegation may be the right fit if your plan includes it and its limits work for you. If you want Devora’s workflow and the application-session model fits your app, open a Devora account and run a staging evaluation. See pricing and security for the rest of the picture.

Sources

• Auth0 Authentication API: Impersonation (Legacy) (opens in a new tab)
• Auth0.NET SDK reference: ImpersonationRequest (deprecation notice) (opens in a new tab)
• Auth0 changelog: Session Delegation in Open Early Access (August 7, 2026) (opens in a new tab)
• Auth0: Session Delegation (opens in a new tab)
• Auth0: Session Delegation behavior and monitoring (opens in a new tab)
• Auth0: Custom Token Exchange (opens in a new tab)
• Devora: Auth providers (opens in a new tab)
• Devora: Auth0 guide (opens in a new tab)
• Devora: Custom session bridge (opens in a new tab)
• Devora: Testing guide (opens in a new tab)