Authentication is a historically boring problem. Developers used to just choose the popular open source library for their framework and run with it (like Devise for Rails).

But in 2021, authentication saw a resurgence as developers and investors alike recognized that this strategy is missing the mark. Past authentication solutions are failing to provide an efficient developer experience for Modern Web frameworks like Next.js, and they're struggling to keep up with the number of sign-in options that today's users demand.

The Modern Web needs a new solution

Authentication for old Model View Controller frameworks was relatively easy. In Rails, Devise provided a current_user variable to both views and controllers, and that was all developers needed. Conveniently, views and controllers ran in the same thread of the same Ruby process, so current_user in both contexts actually referred to the same object in memory.

Compare that to Next.js, the leading Modern Web framework, which already has five different contexts where authentication should work today, plus one more on the way:

1. API routes
2. Edge middleware
3. React during client-side rendering
4. React during server-side rendering
5. React during static generation
6. React server components (Coming soon)

Beyond the quantity of contexts, it's striking how little logic can be shared between them:

• API routes use a Node runtime while edge middleware uses V8 isolates, so memory is not shared between them and the same NPM dependencies may not work in both environments.
• Determining the current user while rendering React on the client-side requires a completely separate security model than determining the current user while rendering React on the server-side.
• Static generation happens at build time so there will never be an authenticated user, but utilities (like a useUser() React hook) still need to gracefully handle the edge case.

And that's still not everything. Unlike Rails which provides ActiveRecord for database access, Next.js developers often use new, standalone solutions like Hasura and Supabase. These tools are unique because they allow frontend developers to query data directly, instead of relying on backend developers to query data for them. You might be wondering, how is data kept secure if it can be accessed directly from the frontend?

Queries to Hasura and Supabase are authenticated per-query, by-user instead of per-connection, by-secret-key. So, instead of backend developers authorizing queries separately (as they did with ActiveRecord), authorization checks are built-in to Hasura and Supabase with Access Control and Row-Level Security respectively.

As a prerequisite for performing these authorization checks, Hasura and Supabase must know which user is currently signed in. And - you guessed it - that means the developer's authentication solution must provide a way to securely inform these tools of the current user. It's a seventh context, on top of the six that already exist just for Next.js.

Considering the proliferation of disparate contexts, it should be no surprise that developers using a Modern Web stack need a robust solution. Authentication is necessary for nearly every project and developers rightfully expect it to work everywhere out-of-the-box.

Clerk is very much focused on the Modern Web, and we already have native authentication solutions for Next.js, Hasura, and Supabase, as well as other Modern Web frameworks like Expo and Gatsby. In 2022, we'll continue to invest more in this stack.

Users want easier sign-in options, or conversion suffers

Open source libraries tend to come with a standard set of features:

1. Sign-up with email and password
2. Sign-in with email and password
3. A forgot password flow
4. A change password flow

This was a great default for years past, but today's users want more options. Even if you're not receiving user requests, the data overwhelmingly shows that extending on these basics will lead to improved conversion.

Across all applications built on Clerk, when a "social sign-in" option is available, like Sign in with Google, just over 50% of all users will choose that option.  And since social options are also more performant (meaning, sign-ups and sign-ins take less time), we always recommend that social sign-in is offered.

With Clerk, adding a social vendor only takes a few clicks, and we provide all the logic to ensure users always access the same account regardless of how they sign in (meaning, users can sign-up with email and password then sign-in with Google).  With traditional open source tools, adding a social vendor often requires adding an extra open source library, and then building the "account linking" logic in-house.

While our recommendation to add social sign-in is ubiquitous, a small portion of developers have also found that replacing the default email and password option can be helpful. This is very application-specific, but a few developers have found success with each of our alternatives:

• Email AND phone sign-ups instead of just email
• Only phone sign-ups
• "Passwordless" with email magic links
• "Passwordless" with SMS one-time passcodes
• "Passwordless" with email one-time passcodes

Similar to adding social sign-in, experimenting between those options with open source tools can require a lot of code-side changes and developer hours. At Clerk, we've developed our <SignUp/> and <SignIn/> components to promote experimentation, and allow applications to switch between authentication options with no code-side changes.

While our list of authentication options is already quite lengthy, we have many more on the way. 2022 will bring Enterprise SAML, Apple's FaceID and TouchID, Web3 solutions like Sign in with Ethereum, and more social sign-in vendors.  We're excited to encourage more experimentation and to help applications provide the best authentication solution for their users.

In summary

2021 cast a spotlight on the shortcomings of traditional authentication tools, particularly as developers change how they build applications, and as users change how they prefer to sign in to applications. As authentication challenges continue to grow in scope, we expect more and more development teams to outsource their solution instead of handling it in-house.