Support impersonation that preserves accountability

Support access should be an explicit, short-lived delegation that preserves both the operator and customer identities on every request. It should never be implemented by changing a support engineer’s session to look indistinguishable from the customer. The system must answer who acted, on whose behalf, under which grant, and why.

Issue a constrained grant

Require the operator to select the tenant and user, enter a case or incident reference, and choose a narrow capability set. The system evaluates whether the operator may request that grant and, for sensitive scopes, whether a second person must approve it. Bind the grant to the operator, subject, tenant, reason, allowed actions, issue time, expiry, and unique identifier. Prefer minutes over hours, and make renewal an explicit new decision.

OAuth 2.0 Token Exchange (RFC 8693) distinguishes delegation, where a service acts on behalf of a user while identifying itself as the caller, from impersonation, where the issued credential continues to identify the user as the authorized entity. For support tooling, delegation semantics produce better accountability. Even if the product calls the feature impersonation, carry both identities to authorization and audit layers.

Deny dangerous operations by design: password and MFA changes, API-key creation, data export, billing ownership transfer, deletion, and consent acceptance are common candidates. Let product owners add domain-specific exclusions. Re-check the grant at the moment of action; hiding a button is helpful interface design, not enforcement.

Make the mode impossible to miss

Show a persistent banner with the customer identity, operator identity, case reference, remaining time, and an Exit button. Use a distinct color and browser title marker. Starting the session should open a new tab or isolated browser context so ordinary operator work cannot accidentally occur under the grant. Never allow support mode to nest or switch directly between customers. Exit first, then request another grant.

The customer-facing interface should explain recent support access where contractual and operational policy permits it: when access started, which support organization acted, why, and when it ended. Keep internal security details private, but do not make the pathway invisible.

Log actor, subject, and effect

The OWASP Authorization Cheat Sheet recommends least privilege and deny by default, and it warns that poor access-control logging can leave violations undetected or unattributable. An audit event should include actor, subject, tenant, grant ID, reason reference, action, resource, outcome, timestamp, policy revision, and correlation ID. Record grant creation, approval, use, expiry, exit, and revocation. Avoid secrets and excessive customer content in logs.

Send real-time alerts for unusually broad grants, access outside assigned cases, repeated denied actions, and emergency revocation. Audit records should be append-only under normal application permissions and retained according to a documented policy. A periodic review should sample whether reasons match cases and whether excluded actions were attempted.

Design revocation before launch

Provide one control to revoke a grant immediately, invalidate active sessions, and block refresh. Customer suspension and operator offboarding should also revoke applicable grants. Test clock expiry, browser refresh, concurrent tabs, operator role removal, and service restart.

A useful launch checklist is short: dual identity reaches every downstream request; sensitive actions are denied server-side; the banner survives navigation; expiry and revocation end access; and audit search reconstructs one session without raw tokens. Begin with one read-only troubleshooting workflow, review its events after a week, and expand scopes only when a real support case justifies them.

Separate troubleshooting from customer consent

Some cases can be solved with metadata, diagnostics, or a customer-shared screen and need no delegated session. Make those the default support tools. When delegated access is necessary, record why the less privileged path was insufficient. This creates evidence for building safer diagnostics and prevents the exceptional path from becoming routine convenience.

If you are implementing this now, start with a single read-only path, require a case reference for every grant, and verify in logs that one support session can be reconstructed end to end before you widen scope.

Reviewed September 2026.