Clerk Changelog

Magic Link API and documentation

We launched email magic link support a few weeks ago for our components, but a few aspects of the API had not been finalized yet. We have now released the API for publicly for developers to build their own magic link flow.

From an API perspective, magic links are our most complex authentication factor, particularly because we do not know if the user will click the magic link from the same device they used to initiate the flow. We provide helpers so developers detect and show different screens depending on the if the link was clicked from the same device or a different one.

Check out the magic link custom flow documentation.

Session token validation documentation

Although we don't have SDKs for every backend language yet, Clerk's session tokens for authentication use standard JWTs, which makes it easy to build your own. Check out our new documentation on validating session tokens.

Twitch SSO support

We added support for another OAuth SSO vendor: Twitch. You can toggle switch on from your dashboard.

New OAuth SSO information page

In addition to building support for Twitch, we've added a new informational page that shares the benefits of using Clerk for OAuth SSO. We love SSO because it's the fastest overall authentication solution we offer, and unsurprisingly considering it's speed, it's also preferred by the majority of users.

Learn more about why we recommend SSO.

Magic links have launched!

And they're the new default. Users signing up will now verify their email address by magic link instead of one-time passwords. Users will also receive magic links during sign if your application uses passwordless authentication, or if they forget their password if your application uses password-based authentication.

The decision to change the default was made after a few weeks testing magic links for our own dashboard. We learned that on average, users are able to sign in faster with magic links. This was the expected outcome since there is no longer keyed entry of the one-time password.

Learn more about magic links on our new product page!

Twitter social sign-in

This week we launched social sign-in with Twitter! Believe it or not, Twitter still uses OAuth 1.0a instead of OAuth 2.0, which caused some extra work on our end. For you though, it's just switch-flick of the User Management settings in your dashboard.

A complete guide to passwordless authentication

Today we launched a guide to passwordless authentication. Passwords have become a point of much debate among developers, particularly because they're often forgotten and they can be susceptible to credential-stuffing attacks. Our new guide breaks down the details and explores the tradeoffs of passwordless authentication.

Full-stack starter with Fastify, React, and Prisma

We released a new starter with Fastify, React, and Prisma – check it out on Github⁠.

Session management as-a-service

Our biggest launch this week is Session Management. As we built support for Next.js authentication at the edge (launched last week), we realized that our session management solution should be launched and marketed as a standalone product.

Our key insight was that developers use "authentication" to refer to two distinct concepts:

• User authentication - when a user verifies their identity to sign-in
• Session authentication - when an application's backend determines which user is making a request

Clerk has always offered both, but the session side of our offering used to be hidden in the background.

Our launch today brings many improvements to our session management offering, and in parallel, begins highlighting the advantages separately. The key advantages are:

• Sub-millisecond session authentication
• Active device management and revocation
• Allowing multiple users to be signed in simultaneously on a single device

Soon, we plan to completely decouple session management from our user management product. This is meant for developers who already have a user management solution, but are looking for one (or all) of the key advantages above.

<UserProfile/> is now extensible

Several developers have asked if they can add more sections to our User Profile component. We've added options to make the component more easily extensible, including an option to hide our default navigation bar so developers can build their own with extra sections.

Discord and GitLab social sign-in

We've added support for social sign-in with Discord and GitLab. Twitter is now under development!

New Guide: Syncing user data to your backend

Most of our customers do not need to sync user data to their own backend, but a few still need to. We've added a guide for syncing data to your backend using Svix, our webhook partner.

Next.js authentication at the edge

Our big launch this week is our new Next.js authentication library that supports sub-millisecond authentication at the edge. This was the culmination of a multi-month project cutting across two teams and we couldn't be happier with the result.

We'll be continuing to improve our Next.js support throughout the end of the year, including first-class support for server-side rendering and React's new Server Components.

Magic link bug fixes

This week we also launched many bug fixes to our upcoming magic link functionality. We have updated our own sign-up form to use magic links instead of one-time passwords sent by email, and we expect to make magic links the default for all new applications soon.

Our changes this week are all about performance. This is a really fun part of our job - since we focus so intently on user management, we get to dive deep to provide the best developer and end-user experiences for our customers.

Sub-millisecond authentication

Applications built on Clerk now use "stateless" authentication by default instead of "stateful." Before this release, our SDKs authenticated users just-in-time with a network request to Clerk's servers. Now, requests are pre-authenticated with signed, short-lived JWTs, and our SDKs verify their signatures in under 1 millisecond.

Each JWT only lasts 60 seconds and the refresh is handled automatically by our frontend SDKs. Since each JWT is so short-lived, end-users and administrators still have the ability to quickly revoke malicious or leaked sessions.

More on this next week, when we'll launch new marketing and documentation pages to fully explain the functionality.

Faster sign-in for password manager users

Our standard sign-in flow has two steps. We do this because it's common for users to forget if they signed up with an email address or with a social sign-in vendor like Google. By asking for a password on the second page, we ensure that a user who originally signed up with Google won't get stuck trying to remember a password that doesn't actually exist.

Although the second step has no negative impact on most users, we have heard some complaints from password manager users. For them, opening the password manager twice can be a hassle.

To improve their experience, we've launched a change that detects when a password manager is available and moves the password field to the first step.

Faster Javascript loading

We've heard your concerns about our large Javascript bundle and have started project to reduce its size. So far, we've dropped 15% to 141 kB, and we'll continue to post updates here until the project is finalized.

Community thank you!

This week, two community projects were launched that we'd like to feature:

1. Miguel Andrade launched a Clerk SDK for Ember.js⁠. Thank you for making Clerk easier to use for Ember.js developers!
2. Jorge Acero launched NextShield⁠, which makes it easy to add authorization to Next.js pages. Thank you for giving developers even more power on top of Clerk's integration with Next.js!

This week was particularly special for Clerk: our team finally met in person!

We raised our initial seed funding as just 2 founders in March 2020, right as the pandemic was spreading across the globe. We've grown to 16 since then, but we hadn't met in person until this week's retreat in Greece. It was thrilling for the team to finally meet each other in person.

"Authentication v2"

This week also marked a major milestone for Clerk as we launched the beta for "Authentication v2."

This is a brand new approach to how developers authenticate their end-users in their backend. We set out to resolve the biggest concerns and most frequent challenges raised by our early customers, namely:

• Authentication now uses short-lived JWTs instead of requiring a network request to Clerk, significantly speeding up the process
• For cross-origin architectures, the authentication token is now passed through the Authorization header to simplify Cross-Origin Resource Sharing settings
• Clerk now works with applications that are rendered server-side
• Clerk now works with backends hosted on the naked domain

Our own website has been running Authentication v2 for the past month and we're excited to open the beta to everyone. To get started, follow the guide here⁠.

Soon, all new applications built on Clerk will default to Authentication v2.

Photo credit: Mark Pitsilos, Clerk engineer and photographer extraordinaire