# Changelog September 30, 2022

## User Impersonation

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:

![JWT token implementation guide](./9f4b870225f0ccdb924e13ac07188b9c1d194007-699x153.png)

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.

### Keeping impersonation safe

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](https://clerk.com/docs/references/backend/sessions/get-session-list.md#get-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.

#### Frontend

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.

```javascript
const { userId, actor } = useAuth()
```

#### Backend

On the backend, it's available through the "auth" helper for the framework of your choice (Next.js shown).

```
import { withAuth } from "@clerk/nextjs/api";

export default withAuth(async (req) => {
  const { userId, actor } = req.auth;
  //...
});
```

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](https://www.rfc-editor.org/rfc/rfc8693.html).

Since the impersonator data is ultimately transmitted through the JWT, this additional context is available with no additional latency.

### Technical deep dive coming soon

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](https://clerk.com/docs/custom-flows/user-impersonation.md#user-impersonation).

Thanks to the contributors: Alex Ntousias, Giannis Katsanos, George Desipris