Does an act claim mean a session is delegated?

In RFC 8693's terms, yes: the act claim says delegation has occurred and names the acting party. In practice, Clerk and WorkOS call these sessions impersonation and Auth0 calls them Session Delegation. In all three, the customer is the token's subject and the agent appears in act.

Which is safer for customer support, impersonation or delegation?

Neither is safe by default. Impersonation gives the agent everything the customer can do, so it needs extra restrictions such as read-only scope. Delegation through admin tools can exceed the customer's own permissions, so it needs narrow staff permissions and careful target validation. Both need the actor recorded.

Should my audit log record the agent or the customer?

Both, in separate fields. The agent is who performed the action and the customer is whose account or data it affected. If an action passes through several services, record the current actor and keep earlier actors as history.

Does Devora do impersonation or delegation?

Devora sessions run in the customer's account, with the customer's identity, so they work like impersonation. Devora keeps the agent and the customer as separate actor and subject fields in the verified context your backend receives. It doesn't provide delegated admin APIs; those belong in your application.

Impersonation vs Delegation for Customer Support

Q: What is the difference between impersonation and delegation?

With impersonation, the agent acts as the customer: requests carry the customer's identity and permissions. With delegation, the agent acts on the customer's behalf but keeps their own identity, so systems can see who acted and for whom. RFC 8693 defines both terms for OAuth token exchange.

Impersonation vs delegation comes down to whose identity the agent uses. With impersonation, a support agent acts as the customer: requests carry the customer’s identity and run with the customer’s permissions. With delegation, the agent acts on behalf of the customer while keeping their own identity, so every system can see who acted and for whom.

The distinction comes from identity standards, but it matters for everyday support decisions: whose permissions apply, what your audit log says, and what can go wrong. Products use “user impersonation” and “user delegation” loosely, sometimes for the same feature. This guide separates them, shows how the major auth providers represent the agent, and maps common support tasks to the right model.

What is the difference between impersonation and delegation?

The clearest definitions are in RFC 8693 (opens in a new tab), the OAuth 2.0 Token Exchange standard. When principal A impersonates B, A gets B’s rights and is indistinguishable from B in that context. In the RFC’s words, “A is B within the context of the rights authorized by the token.” With delegation, A keeps its own identity. Anything A does is understood to be done by A representing B.

Support tools sit on a spectrum between those two:

Model	Who the request says it is	Whose permissions apply	Can your backend see the agent?
Strict impersonation	The customer only	The customer’s	No
Impersonation with an actor claim	The customer, with the agent in `act`	The customer’s, plus any limits you add	Yes, if your code reads `act`
Delegation through staff tools	The agent, with the customer as the target	The agent’s support permissions, scoped to that customer	Yes, the agent is the primary identity

Strict impersonation is the old “log in as the user” shortcut, like a shared password or a reset. It’s the one to avoid, because nothing downstream can tell the agent apart from the customer.

How does RFC 8693 represent delegation?

RFC 8693 describes a token exchange request (opens in a new tab) with a subject_token, for the party being acted for, and an optional actor_token, for the acting party. The resulting token can describe both, which the RFC calls a composite token. Whether the server issues one is a matter of its policy.

In a JWT, the act (actor) claim expresses that delegation has occurred and identifies the actor. The token’s top-level sub stays the subject:

{ "sub": "user@example.com", "act": { "sub": "admin@example.com" } }

Three more details from the RFC are useful for support systems:

Chains. act claims can nest when work passes through several parties. The outermost one is the current actor.
Access control. Systems consuming the token must make access decisions only on the top-level claims and the current actor. Earlier actors in the chain are informational.
Eligibility. A separate may_act claim can state which party is allowed to act for the subject. The authorization server can use it to decide whether to allow a delegation or impersonation request.

How do Clerk, Auth0 and WorkOS represent the actor?

All three put the customer in sub and the agent in an act claim, even though they name the feature differently.

Clerk calls it user impersonation. An impersonated session token (opens in a new tab) includes an act claim whose sub is the impersonator, while the top-level sub remains the user. Your backend can create these sessions with Clerk actor tokens (opens in a new tab).
Auth0 calls it Session Delegation (opens in a new tab). An authorized actor, such as a support agent, establishes a web session as another user, built on Custom Token Exchange. The resulting ID and access tokens both carry an act claim, and Auth0’s implementation guide (opens in a new tab) suggests downstream APIs check it independently. Delegated sessions accept one level of actor (opens in a new tab). Custom Token Exchange access tokens allow up to five nested levels.
WorkOS calls it impersonation. The AuthKit access token (opens in a new tab) includes an act claim with the impersonator’s email, and the authentication response carries an impersonator field with their email and the reason they gave.

So by the RFC’s definitions, these are delegation-style tokens for sessions that behave like impersonation. The agent sees the customer’s screens with the customer’s permissions, and the agent’s identity rides along. The labels matter less than two questions: whose permissions apply, and does your backend record the actor?

For provider-specific setup, see Clerk user impersonation and Auth0 Session Delegation options.

Which support tasks need which model?

Use a session as the customer when the customer’s own view or permissions are the thing you’re investigating. Use delegation through staff tools when the task is something staff should do, not something the customer does.

Support task	Better fit	Why
See what the customer sees: layout, missing data, a confusing screen	Session as the customer, read-only	Their view depends on their data, flags and settings
Reproduce a permission denial	Session as the customer, read-only	Their permissions are what’s under test
Change a setting the customer asked you to change	Delegation, or a write-scoped session with approval	Either works; an admin action records intent more clearly
Apply a credit, extend a trial, unlock an account	Delegation through an admin tool	The customer can’t do these, so their permissions are the wrong boundary
Re-run a failed import or sync	Delegation, as a job with a service identity	Record the agent who started it as well as the service that ran it
Change a password or MFA, accept terms, add a payment method	Neither	These need the customer’s own action or consent

When a session as the customer is the right fit, start read-only. Read-only user impersonation covers which endpoints still need blocking.

What changes for authorization?

The two models fail in opposite directions, so they need different checks.

Sessions as the customer inherit everything the customer can do. An act claim identifies the agent but grants and restricts nothing by itself, so your backend has to read it and apply limits: read-only scope, blocked sensitive endpoints and a time limit. Decide who may open which customer before the session is created, not afterwards. Keep the customer’s normal tenant checks on every request.

Delegation runs on the agent’s permissions, which can exceed the customer’s. That’s the point, and it’s also the risk. Authorize the agent for the specific action, and confirm the target customer and tenant are in that agent’s scope. Never trust a customer ID in the request body because the caller is staff. An admin endpoint that accepts any target is a confused deputy waiting to happen.

In both models, follow the RFC’s rule: base decisions on the subject and the current actor, never on informational history further down the chain.

What changes for audit logs?

Impersonation logs default to the wrong person. If your logger records the token’s sub, every action in an impersonated session looks like the customer did it, unless your code also reads act. Delegation logs have the opposite gap: they record the agent naturally but can lose track of whose account was affected.

Record both identities in separate fields on every consequential event: actor, subject, tenant, action, outcome and a support session reference. For background jobs, add the service identity that ran the work. Audit logs for user impersonation has an example schema.

Where Devora fits

Devora sessions run in the customer’s account with the customer’s identity, so they follow the impersonation-with-actor model. Devora’s verified context (opens in a new tab), which your backend reads on each request, carries the actor (the agent) and the subject (the customer) as separate fields. It also carries the session ID, read or write scope, expiry and how the session was authorized. In Devora’s Clerk setup (opens in a new tab), that context travels in the actor token’s actor object, so it reaches the act claim. Devora’s backend guard (opens in a new tab) enforces the scope on the routes you protect.

Devora doesn’t provide delegated admin APIs. Credits, unlocks and other staff actions belong in your own admin tooling, with your own authorization. Your application also still owns authentication, tenant authorization and business audit events.

If your support tasks fall mostly in the “session as the customer” rows above, create a Devora account and try one staging session. Check that your logs record the agent and the customer separately.

Impersonation vs delegation for customer support