How We Roll – Chapter 3: Multifactor


How We Roll is a deep-dive into how Clerk implements authentication. This chapter is on something you know and something you have: multifactor authentication!

Welcome to How We Roll! This series is meant to help product owners, developers, and security professionals understand exactly how we implement (or, roll) authentication at Clerk.

Chapter 3: Multifactor

Multifactor authentication, or MFA, is the process of authenticating users in multiple different ways before granting access to their account.

It goes by many names. Technologists seem to have settled on _multi_factor authentication because, well, why limit ourselves to two? But two factor authentication is still common and the phrase is used interchangeably.

Within consumer products, though, we've seen the rise of two-step verification:

Google calls the feature "2-Step Verification" or 2SV

Both word substitutions make the concept a little easier to digest, so Clerk has also adopted this language for <UserProfile/> component.

Enough about names, though... How We Roll is for technical details, and naming is the easy part! (Hah.)

Just like passwords, best practices for multifactor authentication have been learned through a history trial-and-error. Let's see how Clerk handles it all!

Self-serve, out of the box

Clerk provides multifactor authentication out of the box, which means it requires zero additional work. How so? The <UserProfile/> component includes a self-serve flow for users to configure multifactor authentication:

Users can choose between one-time passwords sent by SMS (SMS OTP) or time-based one-time passwords (TOTP). Once configured, they also receive backup codes in the event that access to their other factor is lost.

And <UserProfile/> works in tandem with <SignIn/>, so the next time a user signs in, they will be prompted to authenticate with their second factor. No custom code required!

If preferred, Clerk also provides useUser() and useSignIn() hooks, which enable developers to build custom flows for configuring multifactor authentication.

Something you know, something you have

For multifactor authentication, Clerk mandates that each step satisfies a different factor, or type of evidence, for authentication. The two factors we offer are:

  1. Something you know – also called a knowledge factor, is proof that you know something that only you should know, like passwords, security questions, and pins. By extension, it also includes access to another account which is presumed to require a password (like an email account to receive a one-time password, or a Google account).
  2. Something you have – also called a possession factor, is proof that you are holding a physical device. SMS and time-based one-time passwords are both examples, as are newer strategies like passkeys.

It is critical for Clerk to use one example from each bucket. A one-time password sent by email (email OTP) can be a replacement for a password, but a SMS OTP cannot.

Similarly, if a user with multifactor authentication forgets their password, the "forgot password" flow cannot be used to bypass the second factor. Instead, after the user verifies their email, they will still be asked to provide a possession factor.

If a user with multifactor authentication completely loses access to either factor, Clerk cannot directly help that user regain access to their account. Instead, an application administrator can help facilitate account recovery through the Clerk dashboard.

Mitigate SIM swaps at the application level or user level

SMS OTP is a controversial topic among security professions, and rightfully so. SMS is susceptible to a social engineering attack called a "SIM swap," where a telephone company is persuaded to issue a SIM card to an attacker for a victim's phone number.

The general consensus is that SMS OTPs add some degree of security, but a targeted attack has a high chance of success. Jack Dorsey infamously fell victim to a SIM swap which helped an attacker gain access to his Twitter account.

Many argue that SMS OTP should be discontinued entirely. The challenge is that SMS is ubiquitous and convenient, so users are more likely to configure multifactor when SMS can be used.

At Clerk, we don't believe the answer is not one-size-fits all, so our solution is two-fold:

  1. Developers can choose to disable SMS OTP at the application level.
  2. Individual users can choose to disable SMS OTP at the user level. Even if a phone number is added to an account, SMS OTP must be explicitly enabled for it to be used as a possession factor.
Clerk's dashboard allows developers to choose if SMS OTP is enabled


Multifactor authentication is an essential security feature that every application should offer, but it is essential that best practices are followed for knowledge and possession factors. Clerk's components and hooks provide those best practices for multifactor authentication out of the box.

How We Roll Series Index

Colin Sidoti