Clerk Changelog

Add OAuth connections after Sign Up

In the past, when an OAuth connection was turned on, it was required to be available as a sign-up option.

Now, developers can choose whether each OAuth provider is available during sign-up and sign-in, or if the connection should be made later.

This is especially useful for applications that prefer to connect third-parties after the fact. For example, a Github connection can be made after sign-up if an application wants to read repository data.

After sign-up, Connections can be made through our <UserProfile/> component, or with a custom flow.

Thanks to the contributors: Mark Pitsilos, Haris Chaniotakis

Revamped Next.js documentation

We're reorganizing our documentation to have Frameworks at the top-level, and Concepts at the second-level, instead of vice-versa.

We've found that different frameworks uses slightly different concepts (for example, getServerSideProps in Next.js vs loaders in Remix), and that has made it challenging to organize our documentation with Concepts at the top level.

Over the coming weeks, we'll be inverting the documentation to help developers answer their questions faster. The first to get this treatment was Next.js, which is now available here.

Thanks to the contributors: Joe Shekmer

Product Hunt relaunch

Yesterday, we relaunched on Product Hunt to share our progress over the last year. We wanted to add a special thank you in our changelog to our existing customers, who showed up with kind words in the comments and plenty of upvotes. Thank you!

Refreshed branding

Meet the new Clerk! We've refreshed our brand with a new logo, new colors, and a new homepage.

Thanks to the contributors: Charles Wefso, Marcel Cruz, Braden Sidoti

Improved Next.js authentication SDK

We launched @clerk/nextjs v4.5, an easier approach to authentication in Next.js. This standardizes our API in API routes, getServerSideProps, and middleware to a single getAuth() helper.

Thanks to the contributors: Mark Pitsilos, Nikos Douvlis

Backup codes for MFA

Backup codes have been added as a multi-factor authentication method in our <UserProfile/> component, and corresponding APIs have been added to our useUser() hook.

In the <UserProfile/> component, backup codes are presented to the user after configuring either an authenticator applicator or SMS codes for their second factor.

Thanks to the contributors: Haris Chaniotakis

Sign in with Coinbase

Sign in with Coinbase has been added as a Social identity provider. Toggle it on from the Clerk dashboard!

Thanks to the contributors: Haris Chaniotakis

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:

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 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.

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.

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.

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

Component Localization (i18n)

Our components now accept a localization prop, which enables internationalization and customization of our default English strings.

Check out the documentation for more details.

Grafbase, Convex, Nhost integrations

We've launched three additional JWT templates for Convex, Grafbase, and Nhost. Now you can easiliy sync the authenticated user with all of these tools!

Looking for another integration? We're eager to add more, reach out to our team!

Blocklist

In addition to the allowlist, we now support a blocklist. Use this to stop individuals or groups of individuals from signing up.

User bans

Users that already have an account can also now be banned. This action signs out the user from any existing sessions, and prevents them from signing in again.

MFA w/ Authenticator apps

Adding MFA to your app has never been easier... If you've already implemented Clerk, all you have to do is flip a switch.

We've extended our MFA offering to include Time-based one-time-passwords, also known as "TOTP", or, "authenticator apps." TOTP works with almost all modern authenticator apps, such as google authenticator, authy, 1password, hardware devices, and more.

While we've always had MFA w/ SMS, TOTP is a more secure alternative, although harder for some customers to use, and the best security is often security that someone uses1

For this reason, in our own "Clerk Dashboard" We're allowing MFA with either TOTP or SMS. So, go make your clerk account more secure, then let your customers do the same for your app!

You can enable TOTP by going to the clerk dashboard and then:

Configure > Users & Authentication > Multi-factor > Authenticator Apps

How it looks in our new user profile component:

Thanks to the contributors: Mark Pitsilos, Haris Chaniotakis

Updated Settings

On the Clerk dashboard you'll notice a few things moved. Webhooks now have their own home in the sidebar, as do instance-level settings.

We're going to be exposing smaller beta features through this settings page. As of now we have introduced the following settings

• Disable "Have I Been Pwned" password protection

• Enable test mode (this lets you use "fake" emails and phone numbers to sign in, very useful for E2E Testing, on by default for dev instances)

Thanks to the contributors: John Raptis, Sokratis Vidros

Customizable Session tokens

You could always generate custom JWTs with Clerk, but now you can add new claims directly to the Session token encoded in the HTTPOnly cookie.

This token is guaranteed to be up-to-date, and will impose no latency on any requests you make.

You can find this new option in your Dashboard. Navigate to:

Settings > Sessions > Customize Session Token

Thanks to the contributors: Haris Chaniotakis

Clerk Playground

We've created a new "Playground" that lets you easily explore Clerk's React SDK and our APIs. We've tried to keep the examples pared down and simple, so that you can use them as a reference when building your own custom flows. Our plan is to continually add to this repository of examples as a resource to help developers get going quickly with Clerk.

See the live example, or go straight to the repo

If there's a custom flow you want to see built, let us know in our discord

Thanks to the contributors: Ian McPhail, Charles Wefso

Data Processing Agreement

To be in compliance with GDPR, we've updated our data processing agreement and established a formal local presence in the EU.

Read the full agreement here.

Thanks to the contributors: Braden Sidoti