Clerk Changelog

Happy American Thanksgiving! While our US team was off the later half of this week, our global team continued to push out some excellent improvements to Clerk.

Rolling sessions

We now have two session lifetime settings: Inactivity timeout and Maximum lifetime. You can configure your application to use either one, or both.

Inactivity timeout sets how long a user can be inactive before they are logged out, which enables you to set a "rolling" lifetime as long as the user remains active.

Maximum lifetime sets how long a session can last, regardless of activity.

New dashboard beta

We've launched the beta of our new dashboard at dashboard.clerk.com⁠.

During the redesign we put a strong emphasis on organization. Some developers were having a hard time finding the appropriate settings pages in our original dashboard, and we've worked to address those challenges in this update.

Also, our new architecture allows for more rapid development going forward, enabling us to bring new features even faster.

We're still updating screenshots in our documentation to reflect the new dashboard, but we expect to transition completely in the coming weeks.

Rename Return-Path CNAME

To deploy Clerk in production, you must set a few CNAMEs in your DNS that allow us to deliver emails with both SPF and DKIM verification. One of those CNAMEs is for the Return-Path header in the emails.

Previously, the default CNAME was for mail.yourdomain.com, which understandably hit a few collisions. Going forward, the default CNAME is clkmail.yourdomain.com. This is not a user-facing change, it just makes Clerk less likely to conflict with other services you might be using.

Existing production applications still work with mail.yourdomain.com, but please contact support if you'd like to migrate to a different subdomain.

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!