User impersonation has its own vocabulary, borrowed from identity standards, auth providers and security frameworks. This glossary defines the terms that come up when SaaS teams give support staff access to customer accounts, in a sentence or three each.
Terms are grouped into four sections and listed alphabetically within each. Where a term comes from a standard or a provider, the definition links to the primary source. Where one of our guides covers the term in depth, there’s a link to that too. For the bigger picture, start with what user impersonation is and why teams use it.
Who is acting: identity terms
Actor (impersonator)
The actor is the person or system actually performing an action, such as a support agent working in a customer’s account. In impersonation, the actor is also called the impersonator. RFC 8693’s actor token (opens in a new tab) represents “the identity of the acting party”.
Recording the actor is what separates safe impersonation from password sharing. Audit logs for user impersonation shows how to log the actor next to the subject.
Delegation
Delegation is when one party acts on behalf of another while keeping its own identity, so systems can see both who acted and for whom. RFC 8693 says that with delegation semantics (opens in a new tab), the acting party still has an identity separate from the party it represents. Delegated admin tools usually run on the agent’s own permissions, not the customer’s.
Read more in impersonation vs delegation for customer support.
Impersonation
Impersonation is when one party takes on another’s identity and rights, so systems treat it as that party. In SaaS support, user impersonation (“log in as user”) means an authorized staff member opens a separate session as a customer user, without the customer’s password. Under RFC 8693’s definition (opens in a new tab), the impersonator is indistinguishable from the user in that context, which is why support tools record the actor separately. The guide to user impersonation explains how it works and why teams use it.
Subject (impersonated user)
The subject is the user whose identity, account and permissions a session uses. In support impersonation, it’s the customer user, also called the impersonated user. In RFC 8693, the subject token (opens in a new tab) represents the party on whose behalf a request is made. In a JWT, the subject is the top-level sub claim. During the session, the subject’s permissions apply, so the customer’s normal tenant and role checks still decide what the agent can see.
Tokens and standards
Act claim
The act (actor) claim is a JWT claim that says delegation has occurred and identifies the acting party. In a support session, the token’s sub is the customer and act names the agent. It’s defined in RFC 8693, section 4.1 (opens in a new tab). WorkOS impersonation (opens in a new tab), for example, adds an act claim with the impersonator’s email to the access token.
An act claim identifies the agent but doesn’t restrict anything by itself. Your backend has to read it. Impersonation vs delegation covers how Clerk, Auth0 and WorkOS use it.
Actor token (Clerk)
In Clerk, an actor token is a one-time sign-in token, created through the Backend API, that signs a staff member in as a specific user and produces an impersonated session. Clerk’s impersonation docs (opens in a new tab) say the actor you pass when creating the token ends up in the session token’s act claim, and that you can revoke a token before it’s used.
See Clerk user impersonation for customer support for a worked example.
Authorized actor (may_act)
The may_act claim states that one party is allowed to act on behalf of another. An authorization server can read it from a subject token to decide whether a requested delegation or impersonation is allowed, as RFC 8693, section 4.4 (opens in a new tab) describes. It answers “who may act as whom” before a session exists, while act records who did.
Session delegation (Auth0)
Session Delegation is Auth0’s feature that lets an authorized actor, such as a support agent, establish a web session as another user. Auth0’s Session Delegation docs (opens in a new tab) say it builds on Custom Token Exchange, puts an act claim in the resulting ID and access tokens, and records the delegation in tenant logs. Auth0 launched it in Open Early Access (opens in a new tab) on August 7, 2026.
Auth0 user impersonation options compares it with other routes.
Token exchange (RFC 8693)
OAuth 2.0 token exchange is a standard way to trade one security token for another at an authorization server, for example to get a token that acts for a user. RFC 8693 (opens in a new tab) defines the request, with a required subject token and an optional actor token, plus the act and may_act claims. Auth0’s Custom Token Exchange (opens in a new tab) is one implementation, described as defined in RFC 8693.
Access models
Break-glass access
Break-glass access is a pre-defined emergency route that lets a small, named group get access they don’t normally hold, when the normal process can’t be used. Every use should be alerted, time-limited and reviewed. Microsoft Entra’s emergency access guidance (opens in a new tab) reserves such accounts for “break glass” scenarios and recommends validating them at least every 90 days.
Break-glass access to customer data applies the idea to support.
Consent vs approval
Approval is your organization’s decision that a staff member may access a customer’s account. Consent is the customer agreeing to that access. They’re separate records: an internal approval doesn’t show that the customer knew. Microsoft’s Customer Lockbox asks for both (opens in a new tab) when a customer enables it: a Microsoft manager and an administrator in the customer’s tenant must each approve the request.
In Devora, approvals are internal today. A step where the request goes to the customer after internal approval, with the session starting once the customer approves, is on the roadmap.
Just-in-time access
Just-in-time (JIT) access grants a permission only when a task needs it, for a limited time, and removes it automatically afterwards. Microsoft’s PIM documentation (opens in a new tab) defines it as users receiving “temporary permissions to perform privileged tasks”. For support, it means a request, an approval and a time box for each customer account.
Just-in-time access for customer accounts covers how to apply it.
Step-up authentication
Step-up authentication asks someone who is already signed in to authenticate again, or more strongly, before a sensitive action. RFC 9470 (opens in a new tab) defines how an API can tell a client that the current token’s authentication isn’t strong or recent enough, with the error insufficient_user_authentication. In support tooling, it’s a way to confirm the agent is really at the keyboard before a session or a write action starts.
Zero standing access
Zero standing access means nobody holds privileged access by default, so every use needs a justified, approved, time-limited request. It’s also called zero standing privileges. Microsoft uses the term for Microsoft 365 service personnel (opens in a new tab), who have no standing privileged access to production or to customer data.
Just-in-time access is how access gets granted in this model; the JIT guide covers both.
Controls during and after a session
Access history vs audit log
An audit log is a chronological record of system activities, including accesses and operations, in NIST’s glossary definition (opens in a new tab). Access history is narrower: who asked to access which account, who approved it, why, with what scope, and when the session started and ended. Devora’s security page says its access history isn’t a claim that every application action is logged.
You need both. Audit logs for user impersonation shows how they connect.
Endpoint rules
Endpoint rules are method-and-path patterns that control which API requests an impersonation session may make. In Devora’s scope and security model (opens in a new tab), “Always blocked” rules apply in read and write sessions, and read-only exceptions allow one specific write method during read sessions. The backend guard enforces them, and because SDKs cache the rules, an edit normally takes effect within five minutes.
Read-only scope
Read-only scope lets a support session view a customer’s account without changing it. In Devora, read sessions allow GET, HEAD and OPTIONS and block other methods unless a reviewed exception applies, as the scope and security guide (opens in a new tab) explains. Hiding buttons isn’t enough: the backend has to reject writes.
Read-only user impersonation lists what your backend must block.
Row-level security
Row-level security (RLS) is a database feature that limits which rows a role can read or change, using policies attached to a table. In PostgreSQL’s row security docs (opens in a new tab), a table with RLS enabled and no policy uses default-deny, and the table owner is typically not subject to the policies. It’s a common second layer of tenant isolation.
Testing Postgres row-level security as a user shows how to check your policies.
Session termination
Session termination means making a session’s credential stop working on the server, whether it expired, was revoked or the user ended it. The OWASP session management cheat sheet (opens in a new tab) calls server-side invalidation “the most relevant and mandatory” part. In Devora, every ending sends your backend a signed termination request (opens in a new tab), retried if delivery fails, even when no tab is open.
Impersonation session termination covers expiry, revocation and open tabs.
Tenant isolation
Tenant isolation keeps each customer’s data and actions separate from every other customer’s on shared infrastructure. The AWS SaaS Lens (opens in a new tab) calls it foundational: each tenant must be prevented from accessing another tenant’s resources. For impersonation, the agent may open only accounts they’re allowed to, and the customer’s normal tenant checks still run on every request.
Limit support impersonation to assigned customers covers both checks.
Putting the terms together
A well-run support session uses most of these at once. An actor requests just-in-time access to one subject, with a reason. An approver says yes, and the session starts read-only, with endpoint rules blocking sensitive routes and the agent named in an act claim or session data. It ends on a timer or earlier, and the access history and your audit log both show who did what.
If you’d like to see that flow end to end, create a Devora account and try one staging session against a test user.
Sources
- IETF: RFC 8693, OAuth 2.0 Token Exchange (opens in a new tab)
- IETF: RFC 9470, OAuth 2.0 Step Up Authentication Challenge Protocol (opens in a new tab)
- WorkOS: Impersonation (AuthKit) (opens in a new tab)
- Clerk: User impersonation (opens in a new tab)
- Auth0: Session Delegation (opens in a new tab)
- Auth0: Changelog, Session Delegation in Open Early Access (opens in a new tab)
- Auth0: Custom Token Exchange (opens in a new tab)
- Microsoft Learn: Manage emergency access admin accounts (opens in a new tab)
- Microsoft Learn: Microsoft 365 service engineer access control (opens in a new tab)
- Microsoft Learn: What is Privileged Identity Management? (opens in a new tab)
- NIST CSRC: Glossary, audit log (opens in a new tab)
- OWASP: Session Management Cheat Sheet (opens in a new tab)
- PostgreSQL: Row Security Policies (opens in a new tab)
- AWS Well-Architected: SaaS Lens, tenant isolation (opens in a new tab)
- Devora: Security and shared responsibility
- Devora: Scope and security (opens in a new tab)
- Devora: Session lifecycle and cleanup (opens in a new tab)