User Impersonation has been a top 5 request feature since the week Clerk launched. This feature allows admins to sign in as an another user, and experience the application as the user would.
From the Clerk dashboard, admins can now easily sign in as their users with the "Impersonate User" button:
Impersonation is commonly used within customer support and engineering teams to help with debugging. It's helpful to "see what user sees" in these contexts, especially as applications have become more complex and personalized to individual customers.
Like every other Clerk feature, our top piority while developing User Impersonation was security.
Unsafe implementations of User Impersonation are often called "God-mode" because they empower admins to impersonate another user without leaving a trace. This is not the case with Clerk.
Impersonation sessions are automatically logged and can be retrieved from the Session List endpoint of our API.
We've made it possible to detect impersonated sessions as they are happening, so developers can easily choose to prevent actions while a user is being impersonated.
The detection is available on both the frontend and the backend.
On the frontend, information about the impersonator (a.k.a. the "actor") is available through the useAuth() hook. When actor is not null, it's an impersonation session.
On the backend, it's available through the "auth" helper for the framework of your choice (Next.js shown).
If you do not use one of our SDKs, the data is available on the "act" claim of the authentication JWT in compliance with RFC 8693.
Since the impersonator data is ultimately transmitted through the JWT, this additional context is available with no additional latency.
In the coming weeks, we'll continue to share more details about impersonation's design and all of it's capabilities.
Meanwhile, you can learn more in the impersonation documentation.
Thanks to the contributors: Alex Ntousias, Giannis Katsanos, George Desipris
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。