# The Journey to Modern Web Authentication

Web authentication is an acronym and protocol ensemble ([SSO](https://en.wikipedia.org/wiki/Single_sign-on), [OAuth](https://oauth.net), [SAML](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language), [OpenID](https://openid.net/connect), [SCIM](https://en.wikipedia.org/wiki/System_for_Cross-domain_Identity_Management), [FIDO](https://en.wikipedia.org/wiki/FIDO_Alliance), [PKCE](https://oauth.net/2/pkce), [JWT](https://jwt.io), 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](https://reactjs.org), [Vue](https://vuejs.org), [Svelte](https://svelte.dev) or [Angular](https://angular.io) 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](https://en.wikipedia.org/wiki/Multi-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](https://clerk.com/); 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](https://clerk.com/docs/quickstarts/get-started-with-nextjs.md). We knew that React users expect components and hooks, so we offered both of them from the start.

While building our [React components library](https://clerk.com/docs/component-reference/overview.md), 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](https://nextjs.org/docs/basic-features/pages#server-side-rendering), 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 infra­structure 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](https://clerk.com/docs/reference/overview.md). We also moved to [session validation at the Edge](https://clerk.com/docs/request-authentication/nextjs.md#using-edge-middleware) 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](https://clerk.com/docs/organizations/overview.md), we bridged [web3 and web2 authentication](https://clerk.com/blog/introducing-web3-authentication.md), we integrated with JWT-powered databases and tools such as [Hasura](https://clerk.com/docs/integration/hasura.md) and [Supabase](https://clerk.com/docs/integration/supabase.md), we expanded to more React frameworks such as [Remix](https://clerk.com/docs/quickstarts/get-started-with-remix.md), [Redwood.js](https://clerk.com/docs/quickstarts/get-started-with-redwoodjs.md), [Gatsby](https://clerk.com/docs/quickstarts/get-started-with-gatsby.md), [Expo](https://clerk.com/docs/reference/clerk-expo.md), and we've just released our new, fresh, and [fully customizable ClerkJS Components](https://clerk.com/blog/changelog-2022-07-15.md).

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](https://nextjs.org/docs/app/building-your-application/rendering/server-components). In addition, customers request [SSR for our ClerkJS Components](https://github.com/clerkinc/javascript/discussions/183). 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](https://github.com/clerkinc/javascript/issues/127) 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](https://chakra-ui.com) or [Material UI](https://mui.com) 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](https://clerk.com/contact/support) or [apply](https://clerk.com/careers) to join our expanding team. We are an international, all-remote team and we are [currently hiring](https://clerk.com/careers).