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

prop, which enables internationalization and customization of our default English strings.

We've launched three additional JWT templates for 

. Now you can easiliy sync the authenticated user with all of these tools!

Looking for another integration? We're eager to add more, 

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

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.

Changelog September 23, 2022

Password-based authentication systems are prone to various cyberattacks, including brute-force methods, phishing, and keylogging. In 2021, over 

 by attackers. The number of stolen passwords has increased by 

 in recent years, proving how insecure password-based systems are (hint: something passwordless authentication can help with).

Even though applications encourage users to change passwords regularly and use complex and hard-to-guess phrases, it's inconvenient for users. Most users tend to choose a password that's easy to remember and, therefore, less secure.

can help. Passwordless authentication is the process of authenticating without needing to input a password or any memorized secret to gain access, in turn reducing data breaches. According to Verizon's Data Breach Investigations Report (DBIR), 

Passwordless authentication systems come in several different types, including biometric authentication, one-time passcodes, magic links, and social logins; and each has its own advantages and disadvantages. For instance, if you have a web application, biometric authentication or USB-based authentication might not be the best system since you'll need external devices for verification. In such cases, other authentication types, like social logins or magic links, make more sense.

In this roundup, you'll learn about different types of passwordless authentication that are currently available. You'll look at these options and compare them based on their well-supported standards, convenience, security, and promising new technologies.

Different Types of Passwordless Authentication

As mentioned previously, passwordless authentication can mean using either a one-time passcode, magic link, or physical hard disk to give you access to the application. In the following section, you'll learn about different types of passwordless authentication, including their advantages and disadvantages.

 are currently a popular passwordless authentication approach that generates a one-time link and sends it to the user. If the link token verifies with the token stored in the database, the user gets access to the application. The basic workflow looks like this:

In this workflow, a user may enter their email, username, or any specific identifier. The application generates and stores tokens if the user exists on the database and sends a link to the user's email. When the user opens the magic link, the token retrieved from the link gets verified with the backend, and if the token matches, the user gains access to the application. The link stays valid for a specific amount of time, and a user will need to request a new link if it doesn't get authenticated within the allotted time frame.

This workflow may sound simple, but behind the scenes, several complex tasks are happening to ensure that an attacker can be prevented from maliciously accessing the links.

When users need to log in infrequently, magic links provide a frictionless experience that leads to a better user experience. In addition, since no password is stored in a database, there's no chance of a password breach, and the risk of a data breach is also reduced significantly.

. Large organizations in the US allocate almost a million dollars yearly for password-related support costs. With magic links, since no password is attached to the authentication system, there is no need to implement a password-reset solution or a support team.

Even though magic links provide significant benefits, there are also some dependency issues to take into consideration. For instance, if the user's email account gets compromised, the attacker can easily access all applications that authenticate with magic links and use the compromised email to gain access.

With magic links, you also have to worry about email deliverability. Since magic links depend on the user's email, if the email provider is down or the mailbox storage is full, the magic link will not be delivered. In this case, the user won't be able to log in until the mailbox is cleared or the email provider is up again.

In addition, large business-to-business (B2B) companies tend to filter their incoming emails strongly. That means it's possible that a magic link may land in a user's spam folder and affect the overall user experience.

If your application is smaller in size and the frequency of login is fewer, magic link authentication can benefit you. But if a large set audience uses your application and it's essential to efficiently log into the application, you should provide multiple authentication options, like a social login or a password-based login, along with magic links.

One-time password (OTP) authentication is another type of authentication that many modern applications use. This type of authentication sends a passcode (primarily numeric) to the user's registered email or mobile phone. After sending the passcode, the application then asks for the passcode. If the user provides the correct passcode, they can access the application.

OTPs are time-based (just like magic links), and they stay valid for a particular amount of time. After that time frame, a new OTP will need to be generated if the user wants access to the application.

 is a form of network attack in which legitimate data transmission is purposefully or fraudulently duplicated or delayed. Since no password is required in OTP-based authentication and a new OTP is required every time you log in, this type of authentication is safe from replay attacks.

In addition, because OTP-based authentication is provided by most authentication service providers, it's easy to adopt using an authentication service provider like 

. And since no password is involved in authenticating a user, the user doesn't have to remember a password, creating a better user experience.

One of the cons of using OTP is that the messages sent to mobile phones are unencrypted. If the phone or the email address gets compromised, an attacker can easily access the application with the user's profile.

You're also dependent on the network when using OTP. Mobile phone networks might not be stable everywhere and if there's a mobile network issue, the passcode may not get delivered to the user. This can also occur with email if the email provider is down.

Another drawback is that you have to share your mobile number with the application you use. This might be inconvenient and cause issues if your bank account is linked to the same number. Moreover, the provider might call or send the user spam messages; in addition, there is the risk of a data leak. If an attacker gets access to the database, the mobile numbers of all customers can get breached.

The issues with email OTP are similar to the problems associated with magic links. Overall, OTP-based authentication has a few drawbacks, which can be an issue considering there's only one layer of protection. However, your application can be heavily secured using OTP-based authentication as a second layer. For example, with password-based authentication, the chance of getting hacked will be significantly reduced if you integrate OTP as well.

 is a type of login where the user logs in with an existing social account. For example, users can use their Google or Facebook credentials to log into an application, simplifying the login process.

One of the benefits of the social sign-in is that the user doesn't have to fill out a registration form and enter details manually. Instead, when registering with a social sign-in, the necessary details are fetched from the social account. This creates a better user experience.

Another benefit of the social login is that the application can collect more information about the user. This information can be used to provide a better and more personalized experience. In addition, using a social login with familiar login identities helps the user perform login efficiently. Users are already familiar with services like Facebook, Google, and GitHub. Seeing a familiar logo and logging in with the social credentials help the user log in quickly.

One of the disadvantages of the social login is the lack of trust. If users don't trust your application, they might hesitate to share their social details.

In addition, if your application uses social login, then you give the user's control to a third party. If the social platform decides to shut its service or something else happens, your users won't be able to log into your application.

There's also a chance that the user is not providing accurate information on their social profile. In such a case, the application will receive false information about the user, which can lead to a poor user experience.

Social logins can provide a great solution if your application depends heavily on user customization. The data received from the social platform will be helpful for creating a custom experience. But this depends on the niche of your application. If your application is built for more professionals or older adults, this login solution might not be the right solution for your users. However, you could combine a social login with a traditional login system, and you can let the user decide which solution they prefer.

 published the WebAuthn standard in 2016. It's a technology that focuses on securing private information. Rather than using a traditional password-based authentication system, WebAuthn uses 

When a user tries to log into your application, the server sends a challenge to the user. After completing the challenge, the user can access the application. The challenge can be solved by the server's approved method. Most of the browsers and operating systems are building native support for WebAuthn. You can see how WebAuthn works from their 

One of the benefits of WebAuthn is its native support. WebAuthn continues to gain popularity, which means browsers and operating systems are continuously trying to provide native support. API and JavaScript functions (on most major browsers) are also available using WebAuthn.

Because WebAuthn uses public and private key encryption, it's more secure than a traditional password-based system. WebAuthn also doesn't require any password, and because of this, the chance of phishing or man-in-the-middle attack is reduced significantly.

One of the disadvantages of WebAuthn is the lack of currently available support. Because the WebAuthn authentication system is new, not every browser or operating system natively supports it. However, this is rapidly changing, as most modern browsers are integrating the WebAuthn API.

WebAuthn can also be used with hardware authenticators like 

. But in such a case, if the device gets stolen or lost, the recovery might be tricky if there is no proper setup implemented. In addition, because WebAuthn is in a very primitive stage, the 

 is lacking and, at times, can feel too technical to use.

WebAuthn is an excellent alternative to traditional systems, but implementing it for a simple and small application might be overkill. It's ideal for large-scale applications that focus on privacy.

Security Assertion Markup Language (SAML) is an XML-based open standard that transfers data between two parties. You can access all other services linked to your identity by logging into only one platform or dashboard. SAML transfers data between an identity provider and a service provider. The identity provider provides the user's identity and authorizes the service provider. The service provider, based on the identity provider, grants access to the user for the service.

SAML is primarily used in B2B use cases. For example, your company email might let you log into a specific dashboard from which you can access other services.

One of the benefits of SAML is that it provides a great user experience. Only a single credential is needed to log into different applications.

Security is another critical benefit of using SAML. It provides a single point of authentication, and the user's information doesn't leave the firewall boundary. All the different applications don't need to synchronize information between them, making the authentication system securer.

In addition, SAML is widely accepted by enterprises. It has been on the market for a long time and has gained the trust of enterprises.

One of the disadvantages of SAML is that it can be vulnerable to XML and DNS spoofing attacks, which makes the system less secure.

It's not suitable for personal applications like social platforms since setting up SAML is difficult; however, it works well for enterprise applications because employees won't need to think of multiple software that the company uses. Using a single set of login credentials, your employees can access all your software.

In addition, implementing SAML is a critical job. Different security aspects need to be considered, which might not be an easy job for a small-sized team.

Passwordless authentication is gaining more attraction because it's an excellent solution for providing a better user experience and increased security to your users. In this article, you learned about different popular passwordless systems and their benefits and disadvantages.

 can be an excellent solution for your application, but it's crucial that you understand the use case and implement a solution suitable to your needs. 

 to add passwordless authentication to your application within minutes – not weeks.

Passwordless Authentication: Which Option Is Right for Your App

Clerk is launching our first Web3 authentication factor - Sign in with Metamask!

This launch is the result of dozens of developer interviews, focused on understanding if and how Clerk can contribute to the Web3 ecosystem.

It didn't take long before we discovered three common challenges that we can help Web3 developers with immediately: securing sessions, multifactor authentication, and profile enrichment.

First and foremost - we found a near ubiquitous challenge around securing sessions. It's a two-part problem: 

How do you verify a user is owns of a Web3 account?

How do you safely create a session to persist the users account information?

 determine the Web3 account address of a user visiting your website with Metamask connected, just run the following Javascript:

Verifying that the returned address is accurate, however, is significantly more challenging. Developers must ask users to sign a transaction, which is a process that undergone several protocol revisions and is hard to keep up with.

This is where Clerk steps in - all the work of signing a transaction and verifying the signature is abstracted away, and wrapped in a `<SignInWithMetamask/>` button.

Let's be honest - persisting a session isn't a Web3 challenge at all, but it is one that Web3 developers must endure by virtue of operating in Web2 browsers.

We know Web3 developers don't want to think about things like httpOnly cookies, XSS attacks, and session revocation. Web2 developers don't either, and that's why built-in 

 is the foundation of every authentication product at Clerk. We use stateless JWTs that enable authentication in under 1 millisecond, and revocation in under 1 minute. We follow all the best practices so you can focus on building your application.

Sign in with Metamask uses the same abstraction as our other authentication factors like passwords or magic links.

 works with Metamask users out-of-the-box.  Users simply need to navigate to their user profile and opt-in to multifactor authentication. There's no extra work for the developer beyond mounting a 

 component, or redirecting to the Clerk-hosted component.

Off-chain profile enrichment is a topic of much debate in the Web3 community. Ideally, data like email addresses and phone numbers could be retrieved on-chain following the principles of 

But as of today, there are no standard protocols for retrieving this data. As a result, top Web3 companies like OpenSea still collect and verify email addresses off-chain.

Clerk enables developers to easily do the same. We provide simple helpers for collecting and verifying phone numbers, email addresses, and even OAuth accounts. Beyond that, we accept structured data likes names and profile photos, as well as provide a generic metadata field for bespoke profile enrichment.

In the future, we look forward to enriching profiles in a more decentralized manner. Today, we hope this mechanism can help bridge the gap from Web2 to Web3.

Try out our guide for installing Web3 authentication.

  The guide will get you started with a new Next.js application with Metamask authentication.

This launch is the first of many upcoming Web3 launches. Our rough roadmap ahead includes:

 - we know that Metamask alone is a little limiting and will add generic Ethereum support soon

- In the Web2 realm, our team is actively building authorization via Roles and Permissions. We see many corollaries to Web3 authorization via token gating are approaching the primitives in a way that will support both.

 - Because we fully anticipate a multi-chain future

Need something we didn't mention? Please reach out through any of our 

 - we're still defining this roadmap and very interested to hear how we can better meet your needs.

Introducing Web3 Authentication

In this article, we are going to explore how we can use Next.js, Clerk, and Supabase to build a very basic todo app. Thanks to Clerk’s simple and powerful authentication options we're also going to add a complete User Profile, and even Multi-factor authentication (MFA).  

Why would you add MFA to a simple todo app? Because even todos deserve to be protected with the best security. And... Clerk makes it insanely easy to do so with 

Configuring Clerk for authentication by setting up Social SSO, password-based authentication, email magic links, and multi-factor authentication via SMS passcodes.

Configuring Supabase as a backend for a Postgres database, row-level security (RLS) and authorization policies

The source code for the final version can be found 

 is a lightweight react framework that’s optimized for developer experience, and gives you all the features you need to build powerful interactive applications.

 is a powerful authentication solution specifically built for the Modern Web. Clerk lets you choose how you want your users to sign in, and makes it really easy to get started with a suite of pre-built components including <SignIn />, SignUp />, <UserButton />, and <UserProfile />. Clerk also provides complete control with intuitive SDKs and APIs.

 is an open source Firebase alternative. It lets you easily create a backend with a Postgres database, storage, APIs and more. It also has an authentication module, however, for this tutorial we will only be using the database.

The quickest way to get started with Next.js is with the official create-next-app template.

In your terminal, create your app with the following command:

Let’s start with a simpler base by removing most of the Next.js template, and adding a basic nav bar, with a content area for our home page.

Since this is not a CSS tutorial, we'll use some very basic styling and add it all up front.  

As promised, our basic home page will include a simple nav bar and body.

It's going to be beautiful... Let's run our app, and see where we're starting!  

In your terminal, start your application with the following command:

It's easiest to start an app like this with our user object in place, and with a complete authentication foundation.  Then, we can build everything else on top.  Clerk gives us very simple and complete building blocks that makes this whole process very easy.

 to Clerk. Once you verify your email address, you'll be greeted with a way to create your first application:

I'm choosing the default settings, which will collect an email and password, or have users sign in with google.  You can choose whatever you'd like, and once your application is created, you can fine-tune them a lot more in the Clerk dashboard.

When you create a new application, a new development instance is automatically created for you, which is optimized for local development.

Instances in Clerk take a few minutes to be completely ready. Behind the scenes resources are being spun up, DNS records are being set, and certificates are being created.  These take time to fully propagate across the internet, so if you see any errors, give it a minute and refresh.

Now you're going to add sign up and sign in forms, and build a "protected" page, that only signed in users can see.

 to your project. Clerk brings a ton of authentication capabilities to 

, but for this tutorial we'll just set up the basics of sign-up and sign-in.  In your terminal, at the root directory of your project, install the 

this tutorial will be using the latest alpha release, so make sure you're on at least version >=3.0

Now you need an environment variables to link your local development with your Clerk instance.

You can find your API keys on the home page, in the "Connect your application" section.

In your project’s root directory, create a file named 

 . Next.js will automatically load all environment variables set here, into your application.  Because we're not using a custom backend at all, you only need your Frontend API key

Get the values from the dashboard, add the following to your 

 Keys prepended with NEXT_PUBLIC are exposed to your javascript, so do not put 

Any time you add or change your environment variables, you'll need to restart your application, so go to your terminal and kill the running application with 

 and relaunch it with the following command:

Great! although nothing changed, your application can now properly see these environment variables.

Now you can use Clerk's helper components to build a "gated" page.  In order to use these helpers, you should expose the Clerk context to your entire application, by wrapping the top level component with a 

 is the top level of your application. By wrapping the 

 here, every part of your application will have access to the Clerk context.

, add a sign in button and some basic gated content.  We'll use the following Clerk-provided hooks and components:

 - hook to easily access the current user, and it's state

 - displays a "UserButton" for the current user

The header now shows either sign in/up buttons or a 

, depending on your state.  The content section of this page follows similar logic.  Go ahead and sign up, if you sign up with Google, it will pull your profile image, and you will be able to see your 

Clerk provides a lot of hooks, components, and helpers -- you can explore all of them 

There's even more to explore with this application.  The 

You can do a lot from this page, including:

See what devices your logged into, (and log out of unrecognized devices) 

That's right, you don't need to write any more code to add MFA to your application.  Clerk handles it out of the box.  Just go to the 

 tab in your user profile, and follow the steps to add your phone number as a second factor!

This sample app is leveraging Clerk-hosted UIs, which is the simplest implementation path.  There are other ways you can add build this features, including 

 on a page you control, or by building it with a completely custom UI, using the 

Now that your user management foundation is in place it's time to connect to a database and create some todos!

This tutorial is using Supabase as a backend.  Supabase is a very powerful, open-source, postgres-based, database platform.  It will be great for easily storing your todos, and even work as your API.

The first thing you'll need is a Supabase account, which can be created 

. Once you have an account, create a new project.  

And choose the region closest to you, or your users.

Supabase takes a little while to spin up, but once it’s ready, go to the Table editor and press the "Create a new table" button

 and, add 2 new columns to the table named:

For each of the new columns, press the cog and deselect 

With Row Level Security enabled, postgres (and thus Supabase) will deny access to every row by default. So, you will need to setup up some "Policies" that will allow the 

 to access their own rows, and that will let them create new rows for themselves.

Before creating your "RLS Policies", Supabase will need a way to figure out which user is making the current request. You normally would be able to use Supabase's built-in 

currently an issue that we're working to resolve

! Upvote it so the issue can get more attention :) 

The workaround is easy enough though - you will create your own 

function named that accomplishes the same thing as 

NextJS + Supabase + Clerk: Build a simple todo app with multifactor authentication

In short: HttpOnly cookies do not prevent 

 attacks, but they do lessen the impact and prevent the need to sign out users after the XSS is patched. HttpOnly cookies are not a substitute for XSS prevention measures.

Our very first architecture decision at Clerk was to use HttpOnly cookies for session management. It has long been understood that HttpOnly cookies help mitigate cross-site scripting (XSS) attacks, and we felt it was important to include this best-practice directly in our product.

But while there's strong consensus that using HttpOnly cookies is a best practice, we've found many developers are unsure of how they help with XSS. We think this stems from the guidance, which often just says what to do rather than explaining why:

A cookie with the HttpOnly attribute is inaccessible to the JavaScript

 API; it is sent only to the server. For example, cookies that persist server-side sessions don't need to be available to JavaScript, and should have the HttpOnly attribute. This precaution helps mitigate cross-site scripting (

Cookies [...] SHOULD be tagged to be inaccessible via JavaScript (HttpOnly).


After reading this guidance, you might be surprised to learn that HttpOnly cookies do not prevent XSS attacks.

Instead, HttpOnly cookies are helpful when you assume an XSS attack will happen and want to 

. Ultimately, they mitigate XSS attacks by making it easier for organizations to respond.

The specific threat HttpOnly cookies protect against is called 

, which is a fancy way of saying that the attacker is able to steal a user's session token.

When a session token is stored in a cookie 

 the HttpOnly flag, the token can be stolen during an XSS attack with 

. This is problematic because session tokens are the primary mechanism used by backends to authenticate a user.

Once an attacker has access to a session token, they can often act on behalf of a user until that token expires or is revoked. 

Actions can be taken remotely - even if the user is no longer visiting the page with the XSS vulnerability - which can serve to dramatically increase the surface area of the attack.

Conversely, when a session token is stored in a cookie 

 the HttpOnly flag, that token cannot be directly exfiltrated during an XSS attack. This minimizes the surface area of the XSS attack and makes it easier for organizations to respond.

Responding to XSS attacks - without HttpOnly cookies

When an organization is responding to an XSS attack, the first step is always patching the XSS vulnerability.

If HttpOnly cookies were not used, organizations should then assume that session tokens were exfiltrated. This means that - even with the XSS vulnerability patched - the attacker may still have the ability to act on behalf of users.

The next step is revoking the session of any user who may have been subjected to the XSS vulnerability, since those are the users who may have had their session tokens exfiltrated. These users will need to sign in again next time they visit the website.

Lastly, the organization will need to reverse any actions the attacker took on behalf of their users, from the time the vulnerability began to the time session tokens were revoked.

Responding to XSS attacks - with HttpOnly cookies

With HttpOnly cookies, organizations still need to patch the XSS vulnerability and reverse any actions taken on behalf of their users, but they do not need to revoke sessions and ask users to sign in again.

What about localStorage and sessionStorage?

 are newer client-side storage APIs, they function like cookies 

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

Ready to see what Clerk can do?

Pricing