Server-side JWTs for Supabase and custom integrations

Since we launched SSR, a frequent request has been to add support for retrieving Supabase tokens during SSR. Today, we launched the capability for Supabase and more!

Support for every JWT template has been added to our server-side Javascript packages for Next.js, Remix, and Express. Simply call 

 documentation.  You will need to upgrade to the latest version.

Nikos Douvlis

Peter Perlepes

Haris Chaniotakis

Agis Anastasopoulos

Firebase Authentication user and password migrations

Developers who currently use Firebase Authentication can now migrate users and their passwords to Clerk!

 endpoint has added support for Firebase's special flavor of 

 so users can easily be migrated to Clerk.

Alex Ntousias

Any developer who wants to disable Clerk-hosted components on the 

. This option will be made available in our dashboard soon.

Sokratis Vidros

 that brings Clerk's documentation right to your fingertips.

Changelog Mar 18, 2022

Composing an application out of multiple data sources can be challenging, and while Clerk’s Backend APIs work great for most use cases, Webhooks offer the next level of integration that enables you to take full advantage of your existing stack. This post will cover how to synchronize user data from Clerk into your own backend using Webhooks.

 Provider that makes building highly dynamic and interactive experiences with React easier than ever.

Clerk offers a first-class integration with Convex. The queries and mutations living in your Convex instance can be authenticated with a token that was created by Clerk. This integration is covered in more detail 

Convex is also a great target for synchronizing user data from Clerk using webhooks, since you can take full advantage of Convex’s realtime capabilities for user data.

If you are not sure what webhooks are and how to use webhooks with Clerk, it’s recommended to read 

To demonstrate data synchronization with Convex, we can use 

. You can clone and run this repo locally by following the instructions in the repo.

Explain how the demo uses data sync with reactive queries together

Show code examples of the webhooks handler implementation in the demo

The demo application is a chat room where users can send and receive messages. To access the room, a user needs to sign up for an account using the Clerk integration. Once signed in, the user is redirected to a chat room, which establishes a reactive query to the Convex database. This reactive query looks for the user in the database, and returns a “No Clerk User” if the user is not found, and a “Logged In” if the user is found.

Initially after signing up, the user will not be found in the database. Since the signup process happened with Clerk, Convex has no record of this user.

This is where webhooks come into play. After the user signs up with Clerk, Clerk will send an http request to a pre-defined URL with data about the sign up. This URL will point to a Convex HTTP Action, which will parse the data and create a record in the Convex database for the user. Now the client can query for this user again and receive the expected response.

But since Convex queries are reactive, the client doesn’t need to retry the query, instead it will automatically receive an update from the server with the user data. This will trigger React to re-render the UI, providing the user access to the chat room.

To look at the webhook implementation, we can open the 

 function is responsible for… you guessed it… handling the Clerk webhook. It’s a function decorated with 

 and receives the HTTP request and a context object to access other Convex resources.

This function runs security validation on the request to ensure that it came from a trusted source, and runs some database mutations based on the type of event received. The mutations simply mirror the event - creating, updating, or deleting a user in Clerk simply results in creating, updating, or deleting the same user in Convex. It forms a copy of the Clerk user table within Convex.

This allows the most powerful feature of Convex - Queries, to access the user data directly, which means the application doesn’t need to make additional requests to Clerk to fetch the user data (also called the n+1 problem), and the user interface can get notified if the data changes (e.g. if the user changes their name or profile picture).

Webhooks are a powerful feature that enable integrations with existing backend tools, allowing you to use their technical potential to the fullest, while also using Clerk's user management capabilities to the fullest. They help glue disjointed parts of the backend together so that you can pick whatever technology suits your use case for storing and processing data.

Ready to Integrate Authentication in Your App?

 to learn more about the webhook events and data that is exposed by Clerk and build your own integrations today!

For more in-depth technical inquiries or to engage with our community, feel free to 

. Stay in the loop with the latest Clerk features, enhancements, and sneak peeks by following our Twitter account, 

. Your journey to seamless User Management starts here!

Clerk Webhooks: Data Sync with Convex

 has become the go-to framework for JavaScript and React development. It has become so popular because of the superior developer experience, performance optimization features, and its ability to facilitate different rendering options and serverless functions with ease. The combination of these attributes makes it an appealing choice for both new and experienced developers.

In Next.js 13, the Next.js team significantly upgraded the capabilities of the framework. Moving to what they call the “App Router,” Next.js is now based on 

 which boast performance upgrades over the previous client-server architecture.

But this shift has also led to a change in how authentication works in Next.js. In this article we want to provide an up-to-date guide on how authentication now works on Next.js so you can easily understand the concepts involved and 

easily add secure authentication to your Next.js applications

App Router paradigm was introduced in Next.js 13

 and is a significant shift in how the Next.js framework works.

Next.js was initially built as a React framework to facilitate server-side rendered and statically generated sites. But as the framework grew, more options became available:

 is where content is rendered on the client side, after the initial page load. This is ideal for pages that don’t require SEO or initial content served by the server. Common for user dashboards or pages behind authentication. You use React state and effects (

, etc.) as you would in a regular React app.

 is where pages are pre-rendered at build time and served statically. Each request receives the same HTML. This is good for content that doesn’t change often and doesn’t need to be updated with every request, such as blogs, marketing pages, and documentation, etc. Here, you use 

 to fetch the required data at build time.

 lets you statically generate pages with the option to update them in the background. Once updated, subsequent requests get the new version. This is useful for content that updates periodically but doesn’t need real-time updates. Like with SSG, you can use 

 interval (in seconds) determines how often the page should be updated.

 means each request is rendered on-the-fly on the server, providing fresh data. It is ideal for pages that need real-time data or when content changes frequently. Also beneficial for SEO. You use 

You could have some pages work with CSR, some SSG, and some SSR. But this also led to confusion and performance issues with sites not optimally built.

Next.js 13 and the App Router are designed to simplify the developer experience within Next.js, and rebuild the framework around 

. With RSC, the default for the entire site is server-side rendering, with each page being opted-in to CSR as needed. This leads to performance gains, as rendering on the server is faster, and you don’t have to send heavy JavaScript payloads over the network for hydration. It also means more sites can work on the ‘edge’ network, where sites are served from multiple servers close to users.

But this does mean that the way developers have been using Next.js thus far has now changed. The old, Pages Router continues to work, and can be used side-by-side with the App Router, but significant changes in how data is served, such as no request/response objects being passed means developers will need to rethink how they work, and how their authentication works.

How authentication works with the pages router in Next.js

How authentication works with the App Router in Next.js

This will give you the ability to use either as you need, and to see the differences in each paradigm when it comes to authentication.

Authentication With the Next.js Pages Router

Before we get into authentication with the App Router, let’s look at how authentication works with the Pages Router in Next.js.

Let’s create a Next.js project. To do this, we use:

You will be prompted to choose different options, but given that we are explicitly using the Pages Router, you’ll want to select “no” when asked if you would like to use the App Router.

Next, we want to add our API keys as environmental variables in an 

Before we go any further, we’ll also make some small changes to our homepage, at 

We’re now ready to start adding Clerk to our code. The first thing we need to do is mount the 

 is the core component of Clerk. It is what handles all the active session data and the user context. Whenever a Clerk hook (or any other components) needs authentication data, it is getting it from the 

 to authenticate any user. This is important because:

To protect your entire application, it is recommended to wrap our main Component in the 

This will protect every page within the application and will make the user context accessible anywhere within the app, but will also opt every page into dynamic rendering.

If you have statically served pages or are using incremental static regeneration, you can wrap route groups further into your application. For example, you might want to leave your marketing site unprotected, but wrap your dashboard components in the 

 to determine the routes that need to be protected. This is in 

 in our root directory. This matcher will put every page and API route on the site behind authentication:

The entire application is now protected. Accessing any page while signed out will redirect you to the sign up page. If we go to the homepage again, we get redirected:

Usually, this isn’t what you want. Your homepage, product, and marketing pages aren’t very helpful if they are behind authentication!

If you navigate to the homepage now you’ll also get this warning:

To make the route accessible to both signed in and signed out users, pass 

To prevent Clerk authentication from running at all, pass 

ignoredRoutes: ["/((?!api|trpc))(_next.*|.+\\.[\\w]+$)", "/"]

, and replace Clerk’s default behavior of redirecting unless a route is included in public routes

So let’s make a change to add a public route:

Now, when we head to the homepage, it is available again:

Great. But now there is no way for us to sign up or sign in. Clerk’s 

 provides helpers for determining whether a user is signed in or note, and conditionally changing the text. Let’s wrap our text in these components:

Here, if a user is signed out, they’ll see a link to a sign up page. This page doesn’t exist yet, so lets create it. It will live at 

Not much to it. If you try to go that page, you’ll be redirected to sign in/sign up, so it will look like its working. But you are actually being redirected because that page hasn’t been defined as a public route in the middleware, so it itself is behind authentication. To get around this, we’re actually going to add it to our environment variables as a special page:

Now, if we go to that sign up page, we’ll get the modal where we can sign up:

Then, as our environment variables say, we’re redirected to the home page:

As you can see, the link to sign in as gone, as it was wrapped in the component that only shows it if you are signed out.

We now have a problem. We are now signed in (great!), but we can’t sign out (uh oh!). We could create a specific link for this as well, but Clerk provides a 

 that allows us to do this easily. Let’s add that to the homepage:

 so it’ll only show when the user is signed in:

Using that button, the user can easily adjust their profile as well as sign out of the application.

Now the user is signed in, they can visit other pages. Let’s create a 

 library to handle user authentication. If a user is not authenticated (determined by the absence of a 

 prop), the page prompts the user to log in. If authenticated, the page displays a personalized welcome message.

 is present (indicating authentication), it fetches detailed user information from Clerk via 

. The fetched data is then streamlined to a simpler format, extracting only necessary fields like the user’s first name and last name.

 function concludes by returning the user data, if any, along with additional props sourced from 

, ensuring the frontend receives the necessary data to render the page appropriately.

Here, the authentication is checked on the server before the page is rendered via 

. We can also check whether the user is authenticated on the client. Let’s create a 

One final part of Next.js we can protect with authentication–

. With the pages router, any route within pages/api is returned as an API. Let’s protect an API route at 

 helper that retrieves the authentication state to protect the API route. If we call this within the browser, we’ll get the user JSON:

You now have a protected Next.js application using the pages router. Let’s move on to the App Router.

Authentication with the Next.js App Router

We’re now going to work through an entire example with 

 Some of this is the same as above, particularly, the set up, but once we get into the actual authentication, there are going to be some differences.

This time, when you are prompted to use the App Router, select “yes”.

We’ll spool up another bare-bones homepage, this time at 

Looks like we have some nicer default styling with the App Router.

. This is the first point at which there is a difference between the pages router and the App Router. With the App Router, we’re going to add the 

Need help?

Company

Company

Changelog Mar 18, 2022

Server-side JWTs for Supabase and custom integrations

Firebase Authentication user and password migrations

Toggleable hosted components

Community spotlight: Slapdash plugin

Start now,
no strings attached

Pricing built for
businesses of all sizes.

Newsletter!

Company

Company

Changelog Mar 18, 2022

Firebase Authentication user and password migrations

Toggleable hosted components

Community spotlight: Slapdash plugin

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.