Build vs buy for user impersonation isn’t really about who provides a “log in as user” button. Most auth providers already have one. The real question is who maintains the support-access workflow around it: who may access which customer, with whose approval, with what restrictions, for how long, and with what record afterwards.
Start with the requirements your team actually has. Check what your auth provider already covers, then price only the gaps. Keeping native tooling is a perfectly good outcome.
First, do you need account access at all?
Write down the support question before designing anything. Could a sanitized configuration view, a request log, a staging fixture or a customer-led screen share answer it? If so, you may not need impersonation.
Impersonation shouldn’t become the default workaround for missing diagnostics. When session replay isn’t enough covers the difference between past evidence and present behavior.
If some tickets do need access, define the minimum: which user, which customer organization, which actions, the reason, the approval rule and the time limit. Write down unacceptable outcomes too, such as an agent reaching an unassigned customer or changing billing settings.
What native tools already provide
Don’t assume every provider offers only a token. Here’s what the main providers document:
- Clerk offers Dashboard impersonation and programmable actor tokens (opens in a new tab). Impersonated sessions carry an
actclaim identifying the impersonator, and token validity is separate from session length. Its pricing page (opens in a new tab) lists 5 impersonations a month on every plan, with unlimited impersonations in an add-on. See Clerk user impersonation. - Better Auth’s admin plugin (opens in a new tab) offers permission-controlled impersonation and
stopImpersonatingto return to the admin account. Impersonating other admins needs a separate permission. See Better Auth impersonation. - PropelAuth offers employee-level permissions, a dedicated audit trail, Email or Slack alerts, session revocation, request-and-approve access, an organization blocklist and per-employee organization allowlists, as its secure impersonation write-up (opens in a new tab) describes. The approval window is separate from session length; sessions are typically one hour and can’t exceed four. That covers much of a workflow, not just login.
- Auth0 has deprecated its legacy impersonation feature (opens in a new tab). It now offers Session Delegation (opens in a new tab), built on Custom Token Exchange, with actor attribution. It’s listed for B2C Professional, B2B Professional and Enterprise plans. Delegated sessions have a fixed two-hour lifetime (opens in a new tab). See Auth0 user impersonation options.
- WorkOS AuthKit offers Dashboard impersonation (opens in a new tab) once an Admin enables it, with a required reason, an
actclaim naming the impersonator and a 60-minute session. See WorkOS impersonation.
If your provider already meets your approval and customer-assignment policy, that’s likely your answer. Switching providers or adding a product needs a specific reason.
Build vs buy decision matrix: who owns what
The first table shows where each option starts. The second shows who owns each responsibility once it’s running.
| Starting point | What it provides | Question to answer |
|---|---|---|
| Clerk | Dashboard and actor-token impersonation | Does the native flow meet your access policy? |
| Better Auth admin plugin | Permission-controlled impersonation and restore | Who maintains the workflow and restrictions around it? |
| PropelAuth | Approvals, org restrictions, alerts, revocation | Is anything you need still missing after configuration? |
| Auth0 Session Delegation | Delegated web session via CTE | Does your plan include it, and do its fixed limits fit? |
| Devora | Requests, approvals, scoped sessions, access history, plus a provider handoff | Does its integration route fit your app? |
| Responsibility | Build in-house | Native or purchased workflow |
|---|---|---|
| Requests and approval policy | You build and run it | Configure the supplied controls and review the policy |
| Which staff may access which customers | You implement the rules | Use supported restrictions where they exist; fill gaps yourself |
| Creating the session | Your provider or app | Still your provider or app; verify the handoff |
| Tenant and business authorization | You | You |
| Read-only and sensitive-action enforcement | You | You integrate and check coverage |
| Ending issued credentials | You build the lifecycle | You verify revocation works for your sessions |
| Linking business actions to the staff actor | You | You; access history alone isn’t a record of business actions |
| Upgrades and failure handling | You own the whole stack | The vendor owns its product; you own the integration and regression tests |
Buying moves some work to a vendor. It doesn’t move accountability. The multi-tenant impersonation checklist covers each row in more depth.
Buying still means integration work
Devora’s support differs by provider (opens in a new tab). Clerk is supported. Better Auth is supported with prerequisites. Auth0 uses an advanced Custom Token Exchange setup. WorkOS uses a limited application-session bridge. Your backend must pass verified impersonation context to Devora’s guard on protected routes. Devora doesn’t replace the provider that creates the browser session.
The details matter:
- The Better Auth route (opens in a new tab) needs an existing staff session in your app and a binding route you write. There’s no packaged helper.
- The Auth0 route (opens in a new tab) uses Custom Token Exchange plus an application session you own. It isn’t a native Session Delegation integration.
- The WorkOS route (opens in a new tab) is an application-owned bridge, not a standard AuthKit session. See WorkOS impersonation for support teams.
If your architecture can’t accept an extra session store or binding route, buying may be the wrong choice even if the workflow features look right.
Fill in a cost worksheet
Use the same requirements and time horizon for every option. Leave cells blank until the responsible engineer gives an estimate or you have current vendor terms. Include subscription fees from vendor pricing pages (Devora’s are on pricing), but don’t treat the subscription as the whole cost of buying.
| Work item | Build in-house | Native setup | Purchased integration | Recurring work and owner |
|---|---|---|---|---|
| Requirements and access-policy review | ||||
| Approval UI and access records | ||||
| Provider setup and session handoff | ||||
| Tenant and target eligibility | ||||
| Backend restrictions and route coverage | ||||
| Expiry, termination and restoration | ||||
| Audit correlation and privacy review | ||||
| Staging tests and security review | ||||
| Upgrades, monitoring and incident handling | ||||
| Vendor fees and usage assumptions | ||||
| Exit plan and migration |
Write the assumptions next to each estimate: how many apps, which auth versions, how many protected routes, review cadence and expected usage. Don’t compare one option’s full lifecycle with another’s setup cost alone. Unknown maintenance effort is an open question, not zero.
Decide with staging evidence
Whatever you choose, require evidence that:
- An unauthorized staff member can’t start access.
- Changing the target can’t cross into another tenant.
- Blocked actions fail on direct API calls.
- The staff actor shows up in your application’s audit events.
- Ending access rejects the next protected request.
Also test partial failures: the session is created but binding fails, approval changes mid-session, or the session store is unavailable. Record the exact provider and SDK versions, assign a reviewer, and keep any failures visible in the decision record.
Choose native tooling when it meets your requirements. Build when your control needs are specific enough to justify maintaining a workflow. Consider Devora when its route fits your provider and it fills a gap you’ve confirmed. Review provider fit (opens in a new tab), security and the testing guide (opens in a new tab), then open a Devora account to compare one staging workflow against your current setup.
Sources
- Clerk: User impersonation (opens in a new tab)
- Clerk: Pricing (opens in a new tab)
- Better Auth: Admin plugin (opens in a new tab)
- PropelAuth: Secure user impersonation (opens in a new tab)
- Auth0.NET SDK reference: ImpersonationRequest (deprecation notice) (opens in a new tab)
- Auth0: Session Delegation (opens in a new tab)
- Auth0: Session Delegation behavior and monitoring (opens in a new tab)
- WorkOS: Impersonation (AuthKit) (opens in a new tab)
- Devora: Auth providers (opens in a new tab)
- Devora: Better Auth guide (opens in a new tab)
- Devora: Auth0 guide (opens in a new tab)
- Devora: WorkOS guide (opens in a new tab)
- Devora: Testing guide (opens in a new tab)