Zero standing privileges for customer accounts: removing support's permanent access
Zero standing privileges means no one holds permanent access to customer data. Inventory standing access, remove it in stages and track the metrics.
Devora field notes
User impersonation and SaaS support engineering.
Practical guides to customer access, authentication, permissions, and investigating account-specific problems.
- User impersonation
- Support engineering
- Security controls
Latest field notes
Designed to help you make the call.
Focused explanations and practical checklists for the security and support decisions behind customer access.
-
-
Okta impersonation: support access, app impersonation and System Log events
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.
-
Audit log examples: what a SaaS audit log should record
What is an audit log, and what should yours record? SaaS audit log examples: event categories, required fields, sample JSON, retention and integrity.
-
Support session recording: should you record impersonation sessions?
Support session recording shows what an agent saw while impersonating a customer. Weigh evidence value against privacy, masking, retention and replay access.
-
Customer consent and internal approval for support access
Customer consent for support access isn't the same as internal approval. Compare notice, per-ticket permission, customer grants and customer-approved requests.
-
Impersonation session isolation: keep support sessions separate across browser tabs
Impersonation session isolation keeps a customer session from leaking into new tabs and reloads. Use separate profiles, per-tab state and a clean end.
-
Sensitive data masking for support access: what read-only doesn't hide
Read-only support access still exposes secrets and personal data. Use sensitive data masking, field minimisation and support views, with a test matrix.
-
Keycloak impersonation: admin console, permissions and support access
How Keycloak impersonation works: the Impersonate action, the impersonation role, fine-grained permissions, IMPERSONATE events and what support still needs.
-
How Devora works: from access request to session end
How Devora runs a login-as-user session: connect your app, request and approve access, enforce read-only scope, end the session and review access history.
-
User impersonation side effects: exclude impersonation from analytics, emails and jobs
Exclude impersonation from analytics, emails, last-seen, billing, jobs and webhooks: tag requests with the real actor, then suppress or attribute each one.
-
Can support impersonate an admin? Define who may act as whom
Impersonation permissions decide who may act as whom. Keep admin and staff accounts out of support's reach, block chained sessions and test it with a matrix.
-
User impersonation tools for SaaS support: what to compare
User impersonation tools for SaaS support compared by category: auth-provider features, framework libraries and support-access products, plus a checklist.
-
Break-glass access to customer data: emergency support without standing access
Break glass access lets support reach customer data in an emergency without standing access: who invokes it, alerts, short expiry, review and drills.
-
Impersonation session termination: expiry, revocation and open tabs
Impersonation session termination needs more than a stop button: expiry, server-side revocation, open tabs, provider APIs and a staging test table.
-
Impersonation vs delegation for customer support
Impersonation vs delegation: acting as the customer or on their behalf under your own identity. How act claims work, and which support tasks need each.
-
Just-in-time access for customer accounts: applying JIT to support
Just-in-time access gives support temporary, approved access to one customer account. Apply JIT to support, compare it with PAM and check your maturity.
-
Bug reproduction when only one customer account is affected
A bug reproduction method for issues that hit one customer account: account-specific causes, the order to gather evidence, a worksheet and a clean handoff.
-
How to test Postgres row-level security as a specific user
Test PostgreSQL row level security as a real user, not a superuser or service role: SET LOCAL ROLE, request claims and a tenant isolation test matrix.
-
Clerk vs Supabase Auth: which fits a multi-tenant SaaS?
Clerk vs Supabase Auth for multi-tenant SaaS: organizations, Postgres RLS, using Clerk with Supabase, and how support impersonation works in each.
-
WorkOS vs Clerk for B2B SaaS: enterprise SSO, user management and support
WorkOS vs Clerk for B2B SaaS: compare AuthKit and Clerk on enterprise SSO, SCIM, organizations, admin tools, pricing models and user impersonation.
-
Better Auth vs Clerk: self-hosted library or managed auth for your SaaS?
Better Auth vs Clerk for multi-tenant SaaS: data ownership, operations, organizations, SSO and SCIM, admin tools, impersonation and migration cost.
-
Clerk vs Auth0 for B2B SaaS: organizations, SSO and support access
Clerk vs Auth0 for B2B SaaS: how they compare on developer experience, organizations, enterprise SSO and SCIM, admin tools and user impersonation.
-
Django user impersonation for support: django-hijack and what to add
How django-hijack works: who can hijack by default, permission hooks, the notification bar, release and signals, plus what a support workflow still needs.
-
Co-browsing vs screen sharing vs user impersonation for customer support
Co-browsing vs screen sharing vs user impersonation: whether the customer must be there, what support can see and do, consent, privacy and when each fits.
-
Audit logs for user impersonation: record the agent and the customer
Impersonation audit logs need the staff actor and the customer subject. Link access approvals to application events, with an example schema and test matrix.
-
Limit support impersonation to assigned customer accounts
Tenant isolation for user impersonation takes two checks: may this agent open this customer, and may this customer reach this tenant? With a test matrix.
-
Build vs buy user impersonation for SaaS support
A build vs buy decision matrix for user impersonation: native auth-provider tools, an in-house workflow or a support-access product, plus a cost worksheet.
-
How to debug customer permission issues without admin shortcuts
How to debug customer permission issues when a feature works for admins but not customers: compare role, tenant, flag and entitlement inputs safely.
-
Read-only user impersonation: what your backend must block
Read-only impersonation gives support read-only access to a customer account. It needs backend enforcement: a contract, side-effect inventory and test matrix.
-
WorkOS impersonation: what AuthKit gives support teams
How WorkOS AuthKit impersonation works: Dashboard flow, reason and act claim, the 60-minute limit and callback errors, and what a support team still adds.
-
What's wrong with a homegrown 'login as user' button
A homegrown login as user feature fails in predictable ways: no approval, no expiry, tokens in URLs, actions logged as the customer. Each failure and its fix.
-
Why you shouldn't ask customers for their password, and what to do instead
Should customers share a password with support? No. Why it breaks MFA and audit trails, and safer options: screen share, co-browsing or approved access.
-
Auth0 user impersonation: Session Delegation and support access options
Does Auth0 support impersonation? The legacy endpoint is deprecated. Compare Session Delegation, Custom Token Exchange and app-owned support sessions.
-
Better Auth impersonation: what support teams need to add
How the Better Auth admin plugin handles impersonation: permissions, stopImpersonating, common errors, and what support teams add for approvals and scope.
-
Clerk user impersonation for customer support
How Clerk impersonation works, with an actor-token example: the act claim, session limits and revocation, plus what a support team still has to add.
-
User impersonation glossary: terms for support access, explained
A user impersonation glossary: actor, subject, act claim, token exchange, just-in-time access, break-glass, read-only scope and more, in plain words.
-
What is user impersonation? Why SaaS teams 'log in as user'
User impersonation lets authorized staff log in as a user without their password. How it works, why support teams do it, the risks and the safe way.
-
Safe user impersonation in multi-tenant SaaS: a practical checklist
User impersonation best practices for multi-tenant SaaS: staff identity, approvals, tenant checks, read-only enforcement, ending access and audit records.
-
When session replay isn't enough: debugging customer issues you can't reproduce
Session replay shows what happened; controlled user impersonation shows the account now. When to use each for permission, tenant and hard-to-reproduce bugs.
Put it into practice
Give your team context.Keep control of access.
Bring approvals, scoped sessions, and access history into your support workflow.