. It contains a rough estimate of when we expect to start and release new projects. Although it's not guaranteed, it's a good glimpse into how we expect the weeks, months, and quarters ahead to unfold.

Out with the old, in with the new! We were nearing capacity for some of our infrastructure and needed to upgrade.

The upgrades successfully deployed with zero downtime!

Over the weekend, we detected an unusual spike in bot activity associated with SMS verifications. We worked with Twilio to determine that this attack was 

 - where attackers are able to steal money by receiving SMS messages.

We've upgraded our systems to detect and put a stop to the suspicious behavior. Though this attack did not manifest in downtime or security issues, the impacted customers were notified and will not be charged for SMS overruns.

Changelog May 27, 2022

Unfortunately, no product is perfect. Once in a while, a user will have a problem with your application and need some help from the support team.

But if the problem is specific to the user–something about their data or their permissions within the product–how can customer support help? They could screenshare with the user, but that requires a lot of setup. They could just get the user to describe their problem and then walk them through the steps to fix it, but that is open to all kinds of errors. They could share their credentials with the support team, but that is a huge security risk!

User impersonation is an admin feature that allows one user, usually an admin or the support team, to take on the identity of another user without knowing their password or other authentication credentials.

It is one of those features that gets missed in an initial roadmap but is critical to the product's long-term success. Without it, your success team flies blind when trying to help customers. Let’s explain why it’s important and how you can implement user impersonation in your application.

The core reason to use user impersonation is troubleshooting and support. If a user reports an issue specific to their account, admins or the support team can impersonate the user to experience the application exactly as the user does. This helps in identifying and resolving the issue more efficiently.

But user impersonation can go beyond just straightforward support. User impersonation can be important for:

: Developers can use impersonation to see how the application or platform appears to users with different roles or permissions. This can be particularly useful for platforms with different user tiers, allowing for testing the user experience at each level.

: In some cases, particularly within enterprise applications, user impersonation can be helpful for training. A trainer can impersonate a user role to guide new users through specific functionalities of the platform.

: If a user cannot access specific data or files, a support team member might use impersonation to access and recover that data on the user's behalf.

: In certain regulated industries, there might be a need to audit user actions or verify data accuracy. Impersonation can allow an auditor to access the system as a specific user to ensure compliance with regulations.

Of course, impersonating users is fraught with risks. Impersonation can easily lead to privacy breaches if not handled carefully. Admins and support can see personal or sensitive information. Also, if not implemented securely, impersonation features can be a potential attack vector for malicious actors. Ensuring that only authorized personnel can use impersonation and that all impersonation activities are logged for auditing is essential.

Because of these concerns, any system implementing user impersonation should have stringent security controls, logging, and auditing. It's also essential to have clear policies about when and why impersonation is used.

Implementing user impersonation is tricky. Literally, you are tricking your application into thinking that you are someone else. Here are the steps to consider through as you add user impersonation to your product:

: Only certain roles, such as admins and the support team, should be allowed to impersonate. As we said above, you should log every impersonation attempt, including the user doing the impersonation, the impersonated user, and the timestamp.

, have user impersonation built in. Use these wherever possible to lessen the likelihood of mistakes–get this wrong, and you can have serious privacy breaches. You should store roles in JWT or sessions to check user permissions.

: When an authorized user requests to impersonate another user, you should store the original user's ID somewhere safe (e.g., in their session or another token), then update the user session/token to reflect the impersonated user's ID. When the user finishes impersonation, you must restore their session/token using the stored original user ID.

: To avoid confusion, the UI should indicate when impersonation is active. A simple banner or color change can be used to show that the admin is in impersonation mode.

Let’s show how this would work with a basic JavaScript application. We’re going to set up two core components to this:

A backend Express server that will handle the actual impersonation.

A frontend React application that will provide the UI for the support team to use.

The backend is where we will incorporate the logic for our impersonation.

We start by importing the two modules needed:

cors for Cross-Origin Resource Sharing (useful when the frontend and backend are on different origins).

We then set up the Express server. We want to use the built-in 

 middleware, enabling the server to parse incoming JSON payloads in requests.

After that, we set up a user array. This array simulates a database of users. Here, you would call your database to check users and roles. We then have to set up some CORS middleware. Without this, our server wouldn’t want to receive requests from our separate frontend.

ensureAdmin is the integral function of the server. This middleware checks if the user role includes "admin." If so, it allows the request to proceed. Otherwise, it sends back a forbidden status. This ensures the user is an admin before allowing them to impersonate another user.

: An admin can attempt to impersonate another user by providing their ID.

Finally, we start our server. Save this as 

With that up and running, we can set up the frontend.

The frontend will mimic the version of the application that an admin would see. When an admin chooses to impersonate, it makes a request to the 

 endpoint. It then updates the UI based on the response to show that impersonation is active. To stop impersonation, it makes a request to 

After importing React and our CSS, the core App function starts by declaring two state variables:

: A boolean state that tracks whether the admin is currently impersonating another user.

: A string state to store and display messages from server responses or errors.

We then have our impersonation functions. 

 is an async function to impersonate a user by sending a POST request to 

 is also an async function, this time to stop impersonation by sending a POST request to 

 to false and displays a message from the server.

We then render our component. A button allows the admin to impersonate a user with ID 1 , and then a banner is displayed when the admin is impersonating another user. If the admin is impersonating, another button appears to stop the impersonation.

So when an admin logs in initially, they see this:

Once they press the button, they start the impersonation:

Then, they can stop the impersonation again:

What are the problems with the solution above? They are myriad.

First, we don’t have any authentication. This not only means the whole system is insecure, but it also means the impersonation is insecure. We’re just sending a plain text ‘admin’ message to the backend to tell them we can impersonate a user. The correct way to do this is using JWT. The token would contain the role information and be authenticated by the backend.

We also don’t have the logic incorporated to actually do anything with the impersonation. Neither do we have all the security checks in place to securely audit and log any impersonation.

We’re missing all this because impersonation is difficult to get right. You are coding an entirely different way to access your application, and you have to do it perfectly to avoid any security or privacy issues.

This is where using a platform like Clerk becomes essential. 

 is incorporated directly into Clerk. All you have to do is call our 

) and the user ID of the user to impersonate (

This returns a token you can then use to impersonate the user for 10 minutes:

You can then use this with the Clerk SDK for impersonation:

There is an even easier way to use Clerk to impersonate a user–through your dashboard. Go to Users in your dashboard:

Then click to open the menu for the user you want to impersonate and choose "Impersonate user":

Then, your support team is ready to impersonate a user straight away.

Adding user impersonation is a must for a well-functioning support team. It gives them to the tools they need to help your customers with their support needs without sacrificing privacy and security.

Getting it right in your application is a big challenge. Using an authentication solution such as Clerk with user impersonation built-in means you can easily have this embedded in your app, and you don’t have to worry about incorporating errors that lead to security issues. Check out the 

 to learn more about setting this up quickly with Clerk.

Empower Your Support Team With User Impersonation

🔑 Prefill Sign Up & Sign In Components

You are now able to prefill email address, username, and phone numbers in the 

 components, either by passing an initialValues prop or by using query strings. Check out 

Users who exist in your account before you enable SAML can now authenticate with your IdP and link an enterprise connection to their account.

 package introduces stable support for Remix v2, without the need for the 

 prefixes of “future-flags”. Since this is a breaking change, a major bump was needed (v3) – to get the latest version, use 

Updated Email Blocking so that blocking an email address will also block all its subaddresses

 for the file-system-based router that was introduced with Expo Router v2

Auth with Clerk, tRPC, and Cloudflare Workers

 explains how to integrate Clerk authentication into a tRPC API running on Cloudflare Workers.

: This YouTube video demonstrates building an LMS platform like Udemy using Next.js, React, Stripe, Clerk, Mux, and Planetscale.

How to Build a SaaS Product with Next.js, Clerk, AWS DynamoDB & Stripe

: This article shows how to build a complete SaaS product from start to finish using Next.js App Router, AWS DynamoDB, Clerk for authentication, and Stripe for payments.

: Learn how to get started with webhooks to build integrations in a Next.js application with Clerk's fully-featured authentication.

 on their recent raise, and for updating the OAuth flow for 

, an open source platform for storing and displaying the certifications you receive, which uses Clerk for auth. Thank you for helping people organize and increase the visibility of their certificates!

, a new project that is using AI to demystify renters’ rights in NYC, for preventing many headaches, and for leveraging Clerk.

Stay tuned for future updates. If you have feedback or suggestions tweet us at 

Need help?

Company

Company

Changelog May 27, 2022

Public Roadmap

Resilience upgrades

Bot detection upgrades

Start now,
no strings attached

Pricing built for
businesses of all sizes.

Newsletter!

Company

Company

Changelog May 27, 2022

Resilience upgrades

Bot detection upgrades

Start now,no strings attached

Pricing built for.css-qa8l2m{color:var(--chakra-colors-primary-500);}businesses of all sizes.

Newsletter!

Start now,
no strings attached

Pricing built for
businesses of all sizes.