Launch Week Day 5: Impersonation
Compared to alternatives like screen sharing, written documentation, or shared login credentials, impersonation provides an effective and secure way for your support team to troubleshoot.
As users interact with your application, at some point they will experience issues and get stuck. Legacy users will get lost in complex states and new users will sometimes overlook reading docs, requiring your support team to assist with troubleshooting.
Problem is that support can’t pinpoint exact issues your user is seeing unless the user screen shares or records a video. Support also needs to disregard any personal or sensitive information that users accidentally reveal when sharing their screen.
The solution is what we’re shipping today: secure, auditable, opt-in impersonation that requires no integration.
Let’s start with the best part: this new feature is free to all WorkOS users. With just a few clicks, support can impersonate a user in the dashboard and see exactly what they see, minus any sensitive data.
Secure by default
When requesting to impersonate a user, it’s mandatory to provide a justification for the request. This reason is logged and can be retrieved later in the sessions detail page by your security team for audits.
When impersonation does occur, an event is emitted, which can be delivered to your systems via webhooks.
For added security, impersonation is an opt-in option for your user, giving them control over who can access their account. From your point of view, impersonation can be globally toggled on or off in the WorkOS dashboard.
Impersonation is powered by Sessions, which we announced a few days ago. Each session is limited to 60 minutes, after which the impersonator is locked out until a new impersonation request is made.
Available immediately
No integration is required, if you’re using Sessions then you have the ability to use this new feature right now.
However, some developers may want to customize the application behavior when the current user is being impersonated. For example, to redact sensitive information in the application’s UI, or prevent the impersonator
from modifying certain fields.
In these cases, the application can detect that the current user is being impersonated using the impersonator field in a successful authentication response.
Similarly, Session access tokens have an additional act
claim containing the impersonator’s email
.
Both of these will allow you to display a warning or banner in your application reminding the team member using this feature that they are impersonating another user and to be careful with the actions that they undertake.
If you’re using the new Next.js library, you can use our provided `Impersonation` component to automatically render a warning when a user is being impersonated.
For more information on how Impersonation works, refer to the documentation.
That wraps it up for day 5 of Launch Week, tomorrow is the 6th and final day where we’ll be revealing big updates to Radix Themes.