Dec 31, 2021
Dec 31, 2021
Authentication saw a resurgence as developers demanded better tools for Modern Web frameworks like Next.js, and users demanded easier sign-in options
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.
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:
Beyond the quantity of contexts, it's striking how little logic can be shared between them:
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.
Open source libraries tend to come with a standard set of features:
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:
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.
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.
Start completely free for up to 5,000 monthly active users and up to 10 monthly active orgs. No credit card required.
Learn more about our transparent per-user costs to estimate how much your company could save by implementing Clerk.
The latest news and updates from Clerk, sent to your inbox.