Secure user impersonation for SaaS teams
Give support and engineering secure access to a customer account when they need to investigate an issue. Customers never share passwords, and you keep your existing authentication. Devora manages approvals, access limits, expiry, and history.
Keep your existing login. Connect with SDKs.Your app controls who signs in. Devora never sees customer passwords. Devora encrypts the temporary token and clears it after your frontend redeems the handoff. See the handoff
How it works
A teammate asks for access to one customer account and says why. An admin approves it. They work inside your app with a visible timer and clear limits. Afterwards, your team can review the access record. This workflow is also called user impersonation or customer impersonation.
Before access
Start with a customer account and a reason. An organization admin reviews the requested permissions and time limit.
During the session
The teammate works in your app. Your integrated backend enforces scope and endpoint rules, while a banner makes customer access visible.
After the work
Close the session and review the access history. See who entered the account, why they needed access, and how it was approved.
Admins can also approve their own requests. Devora records approval of their own request separately. Understand approval roles
Why Devora
Auth providers and open source libraries can create a session as another user. Your team may still need requests, approvals, access limits, session controls, and history. Devora provides those parts in one place. Choose it only when that workflow fits your team.
Your auth provider
A provider's impersonation feature may already meet your needs. Check how your setup handles approvals, scope restrictions, termination, and access review.
A good fit when your existing workflow covers your team's requirements.
Build or use open source
Use libraries and your own code to shape the experience. Your team owns the approval screens, rules, session oversight, and ongoing maintenance you choose to add.
A good fit when custom requirements justify the engineering ownership.
Devora
Give staff a shared workspace for requests, approvals, session controls, and access history, with optional recording. Your app keeps its authentication and data permissions.
A good fit when you want these workflows without maintaining their dashboards yourself.
Devora still needs an SDK integration and backend enforcement. Read the build or buy FAQs
How access works
Devora coordinates approved customer access. It never replaces your login system. Your backend creates the login token, your app validates the login, and your integrated backend enforces the session limits on every request.
The encrypted token copy is cleared when your frontend redeems the handoff.
Customer ID, optional name and email, and access history are retained. See what Devora stores
A teammate clicks Impersonate in Devora after their access request is approved.
Devora requests a credential with a short expiry from your backend, using your existing authentication.
Your backend returns the token. Devora encrypts a temporary copy for the handoff. Your frontend can redeem it once.
The frontend SDK redeems the handoff. Devora clears the encrypted copy and returns the token.
Your authentication validates the login. Your backend SDK enforces the configured access rules for the session.
If the checks pass, the teammate enters the account with a visible timer. They can end the session when finished.
Your team never needs the customer's password. Your app creates and validates the impersonation credential.
Devora retains a customer ID, optional name and email, and access history. Your integration controls any extra customer information it sends.
Screen recording and activity capture start disabled. Enable them only when your team needs them, with masking and retention controls.
Developer experience
Your developer connects user lookup, session creation, and session revocation through the SDKs. Your backend enforces access rules. Your staff then manage requests and sessions in Devora.
Review your auth provider's prerequisites and test the full workflow in staging before rollout.
Explore the setup guide →# Backend · Express
npm install @devorash/node @devorash/express
# Frontend · React
npm install @devorash/browser @devorash/react
devora→Your frontendFor the team behind your product
Open the account behind the ticket. Investigate the issue without asking for a password or another screen share.
Reproduce bugs that depend on a customer's account. Keep your existing authentication and enforce scope in your API.
Give staff a safe, consistent way into customer accounts without spending a sprint on approval screens, audit logs, and admin tooling that only your team maintains.
Investigate a reported workflow in the affected account. Understand the conditions behind an issue before deciding what to change.
Decide who can approve, restrict what can change, end a session from the dashboard, and answer who was in an account, when, and why from the history.
From the blog
Zero standing privileges means no one holds permanent access to customer data. Inventory standing access, remove it in stages and track the metrics.
Okta impersonation can mean Okta Support's read-only access, admins acting as app users, or System Log events. What Okta offers for each, and what to build.
What is an audit log, and what should yours record? SaaS audit log examples: event categories, required fields, sample JSON, retention and integrity.
Before you get started
Devora lets an authorized teammate open your SaaS application as a customer to investigate an issue, without asking for the customer's password. It gives your team a shared workspace to request and approve access, limit what can be changed, end sessions, and review who accessed which account and why.
The staff member gets their own separate session for that account. Devora does not use or end the customer's own login, and it sends nothing to the customer. What the customer can see afterwards depends on what the agent does. A session limited to viewing changes no data, while a write session makes real changes in the account. Devora records who accessed the account, with what scope, and when. Your organization decides whether and how to tell customers about staff access.
Your provider's impersonation feature may already be enough. Devora is useful when you also want a shared request and approval queue, read and write rules, active session controls, access history, and optional recordings in one place. Your provider still creates the app session. Devora adds the workflow around staff access. Compare your existing setup with those needs before adding another tool.
A custom tool or an open source library can be a good fit when your team wants to own the implementation. Devora gives you a maintained workspace for requests, approvals, session controls, and access review. You still integrate your app, but you spend less effort building those internal workflows and their interfaces. The decision is whether you want to maintain that tooling alongside your product.
No. Devora works alongside your authentication. Your backend looks up users and creates and revokes the impersonation credential. Devora manages requests, approvals, and session oversight. The integration depends on your provider: check the support guide before you start, especially for Auth0 and WorkOS AuthKit.
Connect the backend and frontend SDKs. On the backend, implement user search, user lookup, session creation, and session termination, then apply the scope guard to authenticated API routes. On the frontend, connect the login and session end callbacks. Configure keys, allowed origins, and endpoint rules in Devora. This is an application integration and needs testing before staff use it with real customers.
Yes. Choose scope that allows viewing without changes and enforce it through the integrated backend guard. Write requests are blocked unless you explicitly allow an exception. Sensitive endpoint rules can block actions in both read and write sessions. Your developer must protect the relevant API routes and review their behavior. Hiding a button alone is not an access control.
Devora retains an encrypted customer ID and, when supplied, encrypted name and email fields to identify the account in the access workflow. It also stores request and session records, such as the staff member, access reason, scope, approval decisions, and timestamps, along with team and project settings. The login token payload is encrypted and held temporarily for the handoff. Your integration may send extra handoff information. Keep that to what your app needs. Optional recording or activity capture adds further data when enabled.
No. Recording and activity capture are optional and disabled by default. An administrator chooses the capture and masking settings; recording starts with full masking by default. You can use requests, approvals, session controls, and access history without recording customer screens.
Temporarily, in encrypted form. Your backend creates the impersonation token, and Devora stores an encrypted copy for the handoff to your frontend SDK. The handoff can be redeemed once. After successful redemption, Devora clears the temporary database copy before returning the token. Customer identity and access history records are retained separately. Devora does not ask for your customer's password.
Create an account, connect a test app, and walk through one request with your team.