Does Okta support user impersonation?

Only for its own support team. Your Super Admin, or the admin who opened a case, can grant Okta Support read-only admin access to your Okta org for that case. Okta doesn't provide a feature that lets your admins sign in to your application as one of your users.

How do I approve an Okta Support impersonation request?

In the Admin Console, go to Settings, then Account, click Edit in the Give Access to Okta Support section, and grant impersonation for the case. Okta doesn't send an automatic notification when an engineer requests access, so the engineer asks you directly.

What is user.session.impersonation.initiate in the Okta System Log?

It's recorded when an Okta Support engineer actually signs in to your org using access a Super Admin granted. Related events record the grant, extension, revocation and end of that access, so you can see who approved it and when the session happened.

How can admins impersonate users in an app that uses Okta?

Build it in your application. Staff sign in with Okta as themselves, your backend checks they may open that customer, and your app creates its own short-lived support session for the customer while recording the staff member. Okta's developer support has said its impersonation token exchange flow isn't supported.

Is Auth0 Session Delegation an Okta feature?

Auth0 is part of Okta, which completed its acquisition of Auth0 in 2021. Session Delegation is an Auth0 feature for applications that use Auth0 for customer identity. It doesn't apply to an application that signs users in through an Okta org.

Does Devora integrate with Okta?

Not directly. Devora has no Okta recipe. If your application creates its own session after Okta sign-in, you can use Devora's custom one-time session bridge to add requests, approvals, scope and access history.

Okta Impersonation: Support Access and App Options

“Okta impersonation” means one of three things, and Okta handles each differently. Okta’s only native impersonation feature (opens in a new tab) is for its own support team: your admin grants Okta Support read-only, time-limited access (opens in a new tab) to your Okta org for a single support case.

Okta doesn’t offer a way for your admins to sign in to your own application as one of your users. Its developer support team has said in the Okta developer forum (opens in a new tab) that the impersonation token exchange flow isn’t supported. The third meaning is the System Log, where Okta records support access as user.session.impersonation events.

This guide covers all three, and what Okta’s own support access can teach you about building yours.

What does “Okta impersonation” mean?

It depends on who is acting and where. Find your case in this table:

Meaning	Who acts	What Okta provides
Okta Support access to your Okta org	Okta Support engineers	Customer-approved, read-only access tied to a case
Your staff acting as users of your app	Your support team	No native feature; you build it in your app
Impersonation events in the System Log	Okta Support, approved by your admins	Five `user.session.impersonation` event types

How does Okta Support’s read-only impersonation work?

It is access your Okta org grants Okta Support for one support case, and only after an admin approves.

An Okta Support engineer asks you to approve access. Okta doesn’t send an automatic notification when the request is made.
A Super Admin, or the admin who opened the case, approves it: in the Admin Console, go to Settings, Account, click Edit under Give Access to Okta Support, and grant impersonation for the case.
Okta Support gets read-only admin access to your org. Only the support staff on that case can use it.
The access expires on its own. An admin can extend it, but extensions don’t stack. A Super Admin can also revoke it before it expires (opens in a new tab).

The same settings section has a separate option that lets Okta Support access your org settings (opens in a new tab) whenever they open a case and assign it to themselves. Okta’s support documentation (opens in a new tab) says self-assigned cases need their own approval, so decide deliberately whether to give it.

What can SaaS teams learn from Okta’s support access?

Okta’s design is a good template for your own support access. The customer approves, access is tied to one case, it is read-only, it expires automatically, and every step lands in the customer’s own audit log.

Okta pattern	Equivalent in your product
Customer’s admin approves each case	Ask the customer’s account admin first, or record a standing consent they can withdraw
Access tied to a case and its engineers	Link access to a ticket and the agent assigned to it
Read-only admin access	Default to read-only, enforced on your backend
Automatic expiry, explicit extension	A hard time limit, with any extension recorded
Grant, extend, revoke, initiate and end events	The same lifecycle in an audit log the customer can see

Customer approval is the piece most teams skip. The customer consent guide covers when to ask and how to record the answer.

Can your admins impersonate users in an app that uses Okta?

Not with an Okta feature. A developer with a React app using Okta, with one group for users and one for admins, asked how admins could “log in” as a user. Okta Developer Support replied (opens in a new tab) that On-Behalf-Of Token Exchange is meant for microservices, that an Impersonation Token Exchange flow isn’t currently supported, and suggested a management application that queries Okta for users. An earlier forum thread (opens in a new tab), asking how a super user could get a token for another user without that user’s password, closed without a supported method.

On-Behalf-Of Token Exchange (opens in a new tab) keeps the signed-in user’s context when one service calls another. It doesn’t swap in a different user.

What teams build instead is an application-owned support session: a session your app creates and controls, separate from Okta.

Staff sign in with Okta as themselves.
Your backend checks they may open this customer, by role, assignment or open ticket.
Your backend creates its own short-lived session for the customer and stores the staff member’s ID with it.
Every request runs with the customer’s normal permissions, plus your support restrictions, and is logged with both identities.

Never ask customers for passwords, reuse their tokens or script their Okta sign-in to get there.

If your customer identity runs on Auth0, the picture is different. Okta completed its acquisition of Auth0 (opens in a new tab) in 2021, and Auth0 now has a native option. See Auth0 user impersonation and Session Delegation.

How do you monitor Okta impersonation events?

Query the System Log for the five user.session.impersonation event types. Okta’s event reference lists them (opens in a new tab), and its support documentation explains (opens in a new tab) when each is recorded:

Event type	Recorded when
`user.session.impersonation.grant`	A Super Admin grants Okta Support access
`user.session.impersonation.extend`	A Super Admin extends active access
`user.session.impersonation.revoke`	A Super Admin revokes access before it expires
`user.session.impersonation.initiate`	An Okta Support engineer signs in using the grant
`user.session.impersonation.end`	The engineer signs out, or the session expires or ends

Okta’s event reference (opens in a new tab) doesn’t mark these types as event hook eligible, so read them from the System Log API at /api/v1/logs with a filter such as eventType eq "user.session.impersonation.initiate". The API doesn’t return data older than 90 days, according to the System Log query reference (opens in a new tab). For longer retention and alerting, log streaming (opens in a new tab) sends System Log events to Amazon EventBridge or Splunk Cloud in near real time.

Useful alerts: a grant with no matching open case, an initiate you didn’t expect, and repeated extensions.

Keep the scope clear. These events describe Okta Support in your Okta org. They record nothing about impersonation inside your application, which needs its own events. The impersonation audit log guide covers what to record.

Which option should you choose?

Option	Choose it when
Okta Support access as is	You only need Okta’s team to troubleshoot your Okta org
A narrow internal support view	Tickets need data, not the customer’s exact screen
An app-owned support session you build	A few agents, and you can own approvals, limits and logs
Auth0 Session Delegation	Your customer identity is on Auth0 and its limits fit
Devora with the custom session bridge	You want requests, approvals, scope and access history, and your app owns its session

For a wider comparison, see user impersonation tools for SaaS support.

How does Devora fit with Okta?

Devora has no Okta recipe. Its documented provider routes (opens in a new tab) are Clerk, Better Auth, Auth0, WorkOS and a custom session bridge.

If your application creates its own session after Okta sign-in, the custom one-time session bridge (opens in a new tab) can work:

After a Devora approval, your IMPERSONATE handler confirms the target user and returns a short-lived, one-time handoff token.
Your app exchanges it once for its own HTTP-only support session that stores Devora’s context unchanged and expires no later than the approval.
Your backend passes that context to Devora’s guard (opens in a new tab), which enforces read or write scope and the time limit.
Your TERMINATE handler revokes support sessions indexed by Devora’s session ID.

One difference from Okta’s model matters. In Devora’s approval flow (opens in a new tab), an approver or admin in your organization approves requests, not your end customer. If you want customer approval like Okta’s, collect it in your own app for now. Customer approval is on Devora’s roadmap: after an approver or admin in your organization approves a request, it will be sent to the customer, and the session can start only once the customer approves. Your app also still owns authentication, tenant authorization and business audit events.

Test it in staging

Use synthetic users and a non-production Okta org. These are pass conditions to check, not results we’ve run.

Scenario	Pass condition
Agent signs in with Okta and opens a support session	Backend records staff and customer as different identities
Agent not allowed to open that customer	Support session isn’t created
Write request during read-only access	Backend rejects it; data unchanged
Session reaches its time limit	Next API request fails
Access ended while the tab is closed	Support session revoked; next request rejected

If you only need Okta Support to see your Okta org, Okta’s approval flow already covers it. If your team needs approved, scoped access to your own application and your app owns its session, create a Devora account and try one staging session through the custom bridge.

Okta impersonation: support access, app impersonation and System Log events