447: How to (not) implement impersonation

What It Covers

Stephanie and Joelle examine impersonation features in web applications, exploring why developers should question implementation requests, consider security implications, and design admin tooling that solves core problems without hijacking user identities.

Key Questions Answered

• •Impersonation as symptom: Requests for impersonation features often signal inadequate admin tooling. Instead of allowing admins to hijack user sessions, build dedicated admin interfaces where support staff can modify customer settings directly without identity switching.
• •Decouple from current_user: Design resources to accept user parameters rather than relying on global current_user state. Build standard resourceful routes with IDs, then layer vanity URLs as aliases. This enables admins to view any user's dashboard through authorization policies without impersonation.
• •Audit trail corruption: True impersonation breaks observability and analytics. When admins become users, exception logs lose context about who triggered errors, audit trails misattribute actions, and security teams cannot track admin behavior. Maintain admin identity while rendering user-specific views instead.
• •Authorization over identity switching: Implement view-as functionality that preserves admin identity while displaying user perspectives. This approach maintains proper logging, enables differentiated permission sets between admins and users, and prevents security vulnerabilities from session hijacking without sacrificing debugging capabilities.