Web authentication is an acronym and protocol ensemble (SSO, OAuth, SAML, OpenID, SCIM, FIDO, PKCE, JWT, etc...) that traditional user management software implements one way or another. Developers know that adding authentication to an application is a mundane and tedious task and they increasingly choose to outsource it.

Authentication requires user input, usually collected via redirection to authentication pages such as the sign-up or sign-in page. UX-wise the redirection is a clean cut. Things get fascinating in the modern web world with React, Vue, Svelte or Angular applications. Users expect to land and stay on the same tab, sign in fast and securely with a Google-like experience, and maintain their sessions in a safe and unobtrusive way until they log out.

Let's mull over how to build a sign-in form with SMS two-factor authentication (2FA) in React. Where will the state live? Will the sign-in flow be bookmarkable? How will we transform user credentials into a session? Should I use a session cookie or a JWT? How will I ensure that the UI doesn't flicker when a guest user authenticates?

User management software so far offers the necessary authentication features but integrating them into your React application is cumbersome. This is why we've built Clerk; to offer a modern-web customer identity platform that just works.

From early on, our goal was to focus on developer experience. To achieve that we had to start with a framework so we picked the most popular at the time, Next.js. We knew that React users expect components and hooks, so we offered both of them from the start.

While building our React components library, we had to decide how we will package it in order to make it easy to set up and upgrade. Hot-loading the latest version using semantic versioning was our preferred choice. Another requirement was the ability to customize our components to match the look'n'feel of the host application. We decided to start simple with CSS overwrites.

The hooks API design was also exciting. We debated a lot whether const {user} = useUser() should return null or an empty new User() when not authenticated. We spent countless hours trying to figure out how should we store and update the session state. The first iteration resulted in a polling mechanism with a lot of auth data piggybacking.

The initial adoption was really warm. Clerk began to mature. We started designing new components, adding more authentication features, revamping our state management, and improving our developer experience.

In the meantime, modern web frameworks were evolving rapidly. SSR, used mostly for public, static content back in 2020 became the defacto choice for SaaS. Edge computing support for fast API endpoints was added and distributed web infrastructure improved immensely. So we followed. Clerk was ahead of the game and one of the first solutions to add native SSR support for our hooks. We also moved to session validation at the Edge so that verifying the JWT takes less than 1 ms.

In the first half of 2022, the product went from strength to strength. We added organizations, we bridged web3 and web2 authentication, we integrated with JWT-powered databases and tools such as Hasura and Supabase, we expanded to more React frameworks such as Remix, Redwood.js, Gatsby, Expo, and we've just released our new, fresh, and fully customizable ClerkJS Components.

For the second half of the year, we have a lot of exciting epics in the pipeline. First and foremost, we aim to be the first authentication solution that works with React server components. In addition, customers request SSR for our ClerkJS Components. Remember how hot-loading was a great idea two years ago? With strong SSR support, it's not anymore. We have also started working on making all our SDKs isomorphic to seamlessly work on Node and V8 runtimes. And of course, we will expand our customization capabilities, as we intend to allow developers to use their Chakra or Material UI components in their Clerk authentication forms.

On a personal level, I am looking forward to seeing how bleeding-edge web tech will evolve and shape how we build applications. If you are intrigued by any of these topics, talk to us on Discord or apply to join our expanding team. We are an international, all-remote team and we are currently hiring.