# Clerk Blog — Company — Page 4

# How We Roll – Chapter 1: Passwords
URL: https://clerk.com/blog/how-we-roll-passwords.md
Date: 2023-05-19
Category: Company
Description: How We Roll is a deep-dive into how Clerk implements authentication. In this first chapter, we discuss passwords – the original form of 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 1: Passwords

Many consider passwords to be the "original" form of authentication. They have been used in software since long before the internet existed and are championed for their ease-of-use.

Despite being such a common authentication strategy, implementing passwords is a surprisingly complex task. Decades of trial-and-error have taught us best practices for:

1. Choosing passwords
2. Changing passwords
3. Storing passwords
4. Migrating passwords

Let's learn how Clerk handles it all!

## Choosing passwords

Users can choose passwords in three different scenarios: signing up, changing their password, and resetting their password.

In each scenario, Clerk presents the password field:

This field is designed to provide feedback as the user types, and offers three variants of feedback:

### 1. Password is too short

As with every authentication factor, we first referenced [NIST 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) to determine our password requirements. The National Institute of Standards and Technology (NIST) maintains this document specifically to help authentication professionals maintain the security of digital accounts.

There, we learned that 8 characters is the optimal minimum password length, and so we apply this requirement across every Clerk application.

### 2. Password has been breached

NIST guidance also states that passwords which have been breached should not be used again. Password database leaks are unfortunately all-too-common, and many of those databases store passwords in an unsafe manner.

As a result, billions of passwords have been breached and cannot be used again. To determine whether a password can be used, Clerk leverages the well-maintained corpus from [Have I Been Pwned](https://haveibeenpwned.com).

### 3. Password is too weak

Though it's not suggested by NIST, we implement [zxcvbn](https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/wheeler) to measure password strength as a user types. zxcvbn is a battle-tested complexity estimation algorithm, originally developed within Dropbox.

We allow developers to enforce a minimum level of complexity (low, medium, or high), as determined by zxcvbn.

### Customizing requirements

Within Clerk's dashboard, developers can customize the requirements for users choosing a password:

![How We Roll Passwords guide illustration](./b7ea47b66fa674b5ccf0537b86492ccb73b2ca36-1696x1698.png)

Although not recommended because they frustrate users and because NIST advises against them, this screenshot shows how Clerk also allows LUDS-based password strength requirements (lowercase, uppercase, digits, symbols).

## Changing passwords

When changing or resetting passwords, we help users keep their accounts secure with two requirements:

1. The user must authenticate first, including with multifactor authentication if it is enabled on their account. The helps prevent attackers from claiming an account they discover is signed-in on a public device.
2. The user must be given the option to sign out of other devices. This stops attackers who may already have access to an account.

Here's an example in Clerk's forgot password flow:

## Storage

We use the industry-standard, one-way password hashing function called [bcrypt](https://en.wikipedia.org/wiki/Bcrypt) to hash passwords before they are saved to our database. This is essential to prevent passwords from being leaked, *even in the unlikely event that Clerk's database leaks.*

Counterintuitively, bcrypt adds security by being computationally expensive. Trying to break a bcrypt hash by brute-force is impractical, because it would cost too much money (e.g. trying every possible combination of characters).

Although bcrypt is the standard today, it's important to recognize that the standard changes with some regularity. We monitor those changes and will update our preferred strategy as needed.

## Migrations

Although bcrypt is our preferred hashing algorithm, we support importing passwords that previously used a wide variety of alternative hashing algorithms, like argon2, scrypt, and pbkdf2\_sha256.

These hashes will stay in their original format until the user signs in again with their password. At that time, we will replace the hash to use bcrypt going forward. This ensures that even if passwords are migrated from a weaker format, they are continually upgraded to a modern best-practice.

## Summary

Though simple in concept, implementing passwords for authentication is a complex task. Clerk's components and APIs offer best practices in security and user experience out-of-the-box, so developers can stop worrying about authentication and focus on what truly differentiates their business.

## How We Roll Series Index

- [How We Roll – Chapter 1: Passwords](/blog/how-we-roll-passwords)
- [How We Roll – Chapter 2: Avatars](/blog/how-we-roll-avatars)
- [How We Roll – Chapter 3: Multifactor](/blog/how-we-roll-multifactor)
- [How We Roll – Chapter 4: Email Verification](/blog/how-we-roll-email-verification)
- [How We Roll – Chapter 5: Customization](/blog/how-we-roll-customization)
- [How We Roll – Chapter 6: User Profile](/blog/how-we-roll-user-profile)
- [How We Roll – Chapter 7: JWT Single Sign-On](/blog/how-we-roll-jwt-sso)
- [How We Roll – Chapter 8: Sessions](/blog/how-we-roll-sessions)
- [How We Roll – Chapter 9: Infrastructure](/blog/how-we-roll-infrastructure)
- *How We Roll – Chapter 10: Coming Soon!*

---

# Clerk raises $15m Series A led by Madrona
URL: https://clerk.com/blog/series-a.md
Date: 2023-03-22
Category: Company
Description: Clerk surpasses a million managed users and taps into executive experience from Auth0 and Vercel

Today, we're excited to announce that Clerk has raised a $15 million Series A led by Madrona, just a few months after [our seed](/blog/a16z-seed). We're especially thrilled that [Karan Mehandru](https://www.madrona.com/team-profiles/mehandru-karan) has joined our board, who has tremendous experience in our industry from his time on Auth0's board.

More exciting than fundraising, though, is that Clerk is growing – **and fast:**

![Thumbnail: Clerk raises $15m Series A led by Madrona guide](./5715c0ca9de562c76bb02376aa303bbccc6aee99-1902x702.png)

Our growth accelerated in the new year as word-of-mouth and referrals became our #1 source of new customers. Here is some of the incredible enthusiasm developers are sharing on X:

![Thumbnail: Clerk raises $15m Series A led by Madrona guide](./8bb2940b16b1d504e1be0486ac3aa316d178acca-2358x924.png)

We're so grateful for our early adopters who helped hone Clerk into a streamlined solution – **and then told their friends!** Without them, we simply wouldn't be here today.

Of course, our work is far from done. Throughout the year we'll continue launching new authentication features, like SAML SSO, passkeys, and support for more frameworks.

We're also eager to begin helping developers with *authorization*. We'll expand customer profiles to include information about Roles and Permissions, as well as Billing and Entitlements. We'll solve authorization through components and hooks, same as we did authentication.

As always, if there's anything in particular you'd like to see from Clerk, or if you have feedback or suggestions, we'd love to hear from you. Join our [community discord](https://clerk.com/discord) or tweet at [@clerk](https://x.com/clerk) – we're listening and eager to improve.

### Press Release

**Clerk raises $15 million for React authentication and user management**

Clerk, the drop-in authentication and user management solution for React, today announced a $15 million Series A led by Madrona, with managing director Karan Mehandru joining its board. Mehandru brings a deep understanding of the space from his years on the board of Auth0. Other new investors include Vercel's CEO Guillermo Rauch, Mango Capital, and Auth0's former CRO Dave Wilner. Existing investors Andreessen Horowitz, S28 Capital, and Fathom Capital also participated.

*"The response from React and Next.js developers has been incredible. Monthly active users have grown 500% in the past 5 months, and we've crossed a million managed users,"* said co-founder and CEO, Colin Sidoti. *"When we met Karan, we were excited to tap into his experience in identity and in scaling go-to-market as we target the next generation of application development."*

React and frameworks like Next.js have sparked an architecture shift that will propagate across all application development, and this new architecture requires a tailored suite of developer tools. Hosting and database technologies have already evolved, but before Clerk, authentication was left to be solved in-house.

*“Clerk is the Stripe Checkout of authentication and user management, except it’s built for React,"* said Rauch, who also authors Next.js. *"The best practices built-in to their `<SignIn/>` and `<UserProfile/>` components would take months to implement in-house, yet no sacrifice is made in terms of Enterprise extensibility or customization to your brand.”*

With this new funding, Clerk will accelerate its roadmap beyond authentication. It aims to help developers with authorization, which requires knowledge of a user's role and permissions, as well as their billing plan and entitlements. Clerk will provide the glue that binds these systems together, while also empowering React developers to build authorization controls for their end-users.

*"Clerk is a foundational technology company dedicated entirely to serving the needs of the next generation of application developers as the authentication industry migrates from back-end APIs to front-end componentized modules,"* said Mehandru. *"As this market evolves, Clerk is extremely well positioned to be the "system of action" and the "system of record" for customer identities, much like what Auth0 accomplished in the last decade. I am excited to partner with Colin, his brother and cofounder Braden, and the Clerk team as they empower the developers of the future and build an enduring and exciting company over the next decade and beyond."*

Clerk is actively hiring across product and engineering roles. Please visit [clerk.com/careers](/careers) for more information.

---

# Clerk raises $6.2m led by Andreessen Horowitz
URL: https://clerk.com/blog/a16z-seed.md
Date: 2022-11-30
Category: Company
Description: Clerk is building the future of authentication for React, where the Component is the new API

Today, we're thrilled to announce $6.2m in new funding led by Martin Casado at Andreessen Horowitz, with continued participation from S28 Capital, Fathom Capital, and South Park Commons. The formal press release is available below.

This funding marks a major milestone for Clerk. For the first time, we've raised based on the traction of our customers, who are simply blowing us away with their continued success. Here's a chart showing cumulative sign ups across all customer applications since we launched:

![Cumulative customer sign-ups chart](./33e2503da8bdd68d27f8100245b0e13c0faf8a3d-1940x762.png)

Our key insight at Clerk is that the Component is the new API. In fact, over 95% of our customers use **all** of our `<SignUp/>`, `<SignIn/>`, and `<UserProfile/>` components! Of the few who implement our APIs directly, most will build a custom sign-up flow with our APIs, but still use our `<SignIn/>` and `<UserProfile/>` components for efficiency.

This outcome is obvious in hindsight. Components combine the power of backend APIs with beautiful, prebuilt frontends, so they inherently deliver more value than APIs alone. We believe component-based integrations have set a new standard for developer tools, and we're excited for the massive improvement in developer productivity they enable.

With this new funding, Clerk will reinforce and expand on our foundation, including:

- Continued, emphatic support for cutting-edge frameworks like Next.js, Remix, Redwood, and more on the way
- Additional authentication strategies like passkeys and SAML SSO
- Expanded capabilities in our `<CreateOrganization/>` and `<OrganizationProfile/>` components for B2B SaaS

We can't wait to see what you build!

### Press Release

Clerk, the drop-in authentication and user management solution for React, announced today that it has closed a $6.2m seed round led by Andreessen Horowitz. Existing investors S28 Capital, Fathom Capital, and South Park Commons also joined the round. This new funding will allow Clerk to expand its suite of authentication and user management tools, and create new tools to help B2B SaaS companies manage both user accounts and business accounts.

Clerk empowers React developers to build sign-up and sign-in flows as well as user profiles without the assistance of backend developers. The solution comes complete with security essentials like multi-factor authentication and active device management. The beautifully designed React components can be customized to match any company's branding. By providing a full stack solution, Clerk minimizes the time engineers need to spend on authentication, freeing up development resources to focus on the core of their business.

The vast majority of authentication solutions on the market today are still managed in-house and are often incomplete and fail to meet security best practices. Many of these solutions are dated, as web development technologies have evolved to component-based frontend technologies like React. With Clerk’s solution, developers are getting what they prefer—components—because they help them move faster. Components are especially appealing in authentication and user management where businesses do not get much benefit from reinventing the wheel of self-serve 2FA or avatar-uploading. Clerk includes both in their `<UserProfile/>` component.

*"Our key insight is that React Components have replaced REST APIs as the premier developer experience,"* said **Colin Sidoti, Clerk cofounder and CEO**. *"Since components have a built-in backend and presentation layer, they're an order-of-magnitude faster to implement than APIs."*

While Clerk is intended for React frontends, the authentication solution works with any framework, programming language, or API gateway on the backend. This approach has been especially helpful for legacy web applications that are transitioning to React on the frontend, but do not want to change their backend technology.

*"There's a growing preference for React among businesses of all sizes, and devtools must evolve to cater to this new architecture. Clerk is hands-down the easiest and most-complete approach to auth and user management in React today,"* said **Martin Casado, General Partner at a16z.** *"We are excited to help accelerate Clerk's growth and reach more businesses, founders and startups who are looking for easy authentication and user management."*

Clerk's vision is to build a truly complete customer management solution for developers, helping facilitate authentication, authorization, communications, billing, and more. Clerk believes these essential services can all be bundled together, and presented cohesively in simple React components.

Notable startups using Clerk include database company Grafbase, women's shapewear company Honeylove, and apartment rental company Blueground. Clerk's React-optimized solution has led the company to be included in Netlify's Jamstack Innovation Fund, and named one of the [10 most promising Jamstack startups](https://www.netlify.com/blog/jamstack-innovation-fund-launches-with-the-10-most-promising-jamstack-startups).

---

# A ‹Component/› is worth a thousand APIs
URL: https://clerk.com/blog/a-component-is-worth-a-thousand-apis.md
Date: 2022-08-07
Category: Company
Description: Clerk is the only authentication service that offers a User Profile component. It sounds incremental, but it's 10x more work – this post explains why

Clerk started with a simple vision. We loved the professionalism of Google's Sign Up, Sign In, and User Profile, so we set out to build developer tools that would help everyone match their caliber.

![A Component Is Worth A Thousand Apis guide illustration](./a0904584e9cb4e0751a833c1bc0bdd14f5060fa2-1080x494.png)

With UIs as our primary goal, we realized that Clerk wouldn't be a traditional API company. We focused on building a fantastic frontend component SDK, rather than a traditional backend REST SDK.

We chose React as our first target given its popularity, and split Google's surface area into four components: `<SignUp/>`, `<SignIn/>`, `<UserProfile/>`, and `<UserButton/>`.

![A Component Is Worth A Thousand Apis guide illustration](./e9dbf939e2b523fdf51e5f9e59a6f5e16907298b-2458x1248.png)

Components are a higher-level of abstraction than REST SDKs. They provide UIs to end-users instead of just a function to developers, so they inherently offer more value.

But what's surprising is just *how much* more value. Even at Clerk, we assumed we could just "slap a UI on top of an auth API." Despite having a team full of seasoned engineers, we failed to realize just how much work sits between traditional APIs and the end-user features they enable.

### Stripe example

As an example outside of authentication, let's compare Stripe's original 9 lines for creating a charge, to the *sidebar* for their current Checkout documentation:

![A Component Is Worth A Thousand Apis guide illustration](./cccc2d59d94fa8b00928e84940a25f5392dbbb90-1082x981.png)

Checkout has far more complexity than the original Charge API, but why? Aren't both responsible for charging a customer?

The difference is that Charge asked for the exact amount to charge, while Checkout needs to display *why* an amount is being charged. It needs all of the context of the Products being purchased, their Price, the quantity, the taxes and shipping costs, any discounts applied, and more. Stripe needed to build dozens more API resources and paramaters to produce the end-user Checkout UI.

Before Checkout, this additional context lived inside the developer's application. Now that it lives inside Stripe, charging customers has become massively easier. Stripe solves so much more complexity for developers today than it did 10 years ago.

### Clerk example

Clerk is seeing the same patterns in authentication that Stripe saw in Checkout. To build our core components, we need to manage much more complexity than legacy vendors like Auth0.

This is particularly apparent with our `<UserButton/>` and `<UserProfile/>` components. We are the only authentication provider to offer these, and there's a foundational reason why: **Clerk is the only authentication provider that manages sessions as-a-service.**

Legacy vendors focus on just the sign-up and sign-in screens. Once the user's identity is verified, the session is managed within the application – not within the authentication service. This makes it impossible for them to offer drop-in `<UserButton/>` and `<UserProfile/>` components like Clerk.

And since we're not ones to cut corners, our session management solution is fully featured. We include active device management from within `<UserProfile/>`, so users can remotely force sign outs from other devices:

![A Component Is Worth A Thousand Apis guide illustration](./3135b92fe15d7d789429299c6354d1662ea941b1-616x391.png)

Plus, we (optionally) include account switching within `<UserButton/>`, just like Google's:

![A Component Is Worth A Thousand Apis guide illustration](./c962088265770e23f04b1cf2b0b5eeba2c32d2b6-471x527.png)

Beyond session management, we also enable self-serve two-factor authentication from within `<UserProfile/>`:

![A Component Is Worth A Thousand Apis guide illustration](./dfec3db47a85e8f1f17f882a97c2b00bcbdf2ab5-615x352.png)

Once setup is completed, `<SignIn/>` will automatically request the second factor during the next sign-in:

![A Component Is Worth A Thousand Apis guide illustration](./478885fd08c6525391c6878688bea54c3d091274-526x527.png)

If Clerk didn't manage sessions and two-factor authentication, developers would be stuck implementing these features from within their application – a much more challenging prospect than simply using `<UserButton/>` and `<UserProfile/>`.

### On components vs redirects

Some readers may be aware that Clerk uses embeddable components while Stripe Checkout uses a redirect flow. That's completely correct, so we kept this blog focused on points that remain true regardless of how the UI is ultimately presented to the end-user.

That being said, there is one advantage to components that deserves a special callout:

At Clerk, every component we build is composed using React hooks, and the hooks we use are actually pacakaged alongside our components. So, if frontend developers don't like our components for any reason, they can still build their own UIs **without involving a backend developer and a backend SDK.**

This extra layer of composability has been a huge boon for companies with strict branding requirements, since we eliminated the need for backend application logic regardless of if our UIs are used.

### In summary

We've seen this pattern enough to say confidently: **a `<Component/>` is worth a thousand APIs.**

Components have become the new gold-standard in developer tools – they are the new, optimal, composable building block. They save developers far more time than traditional REST SDKs, both by providing end-user UIs, and by eliminating huge swaths of code that used to be managed in-house.

---

# The Journey to Modern Web Authentication
URL: https://clerk.com/blog/the-journey-to-modern-web-authentication.md
Date: 2022-07-21
Category: Company
Description: A blog post about the story of Clerk; our journey of bringing seamless authentication to the Modern Web, where we stand now, and what lies ahead.

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](/); 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](/docs/quickstarts/get-started-with-nextjs). We knew that React users expect components and hooks, so we offered both of them from the start.

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

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](/careers) to join our expanding team. We are an international, all-remote team and we are [currently hiring](/careers).

---

# Clerk joins the Netlify Jamstack Innovation Fund
URL: https://clerk.com/blog/clerk-joins-netlify-jamstack-innovation-fund.md
Date: 2022-07-12
Category: Company
Description: Clerk powers authentication for over 5,000 Jamstack teams – now we're working with Netlify to further our commitment to the ecosystem

Clerk provides serverless, edge-compatible authentication to over 5,000 Jamstack teams. Today, we're thrilled to join the Netlify [Jamstack Innovation Fund](https://www.netlify.com/jamstack-fund) to further our commitment to the ecosystem.

Netlify has been an inspiration for Clerk since their co-founder, Matt Biilman, [spoke about Jamstack in 2016](https://vimeo.com/163522126). The idea felt like it would change the way we build software, *and indeed it has*.

Clerk leverages Jamstack to set a new standard for developer tools. Instead of only providing a backend SDK, we also offer a frontend SDK with React components and hooks to empower frontend developers.

For example, our [`<SignUp/>` component](/components/sign-up) embeds a complete, conversion-optimized sign-up flow in our customer's application:

![Clerk Joins Netlify Jamstack Innovation Fund guide illustration](./9507286557ea85867e815093a4f0108edfa4cdf8-720x486.svg)

And for complete customization, frontend developers can instead leverage our [`useSignUp()`](/docs/reference/clerk-react/usesignup) hook to build a UI of their own.

Both `<SignUp/>` and `useSignUp()` are implemented entirely on the frontend, while Clerk's API is responsible for the backend of user and session management. This enables teams to build fully-featured authentication in minutes instead of days or weeks.

We're proud to be recognized as one of the 10 most promising Jamstack startups, and excited for the future as we begin working closely with the Netlify team. Stay tuned!

---

# Clerk is hiring a senior frontend team to expand our full-stack component library
URL: https://clerk.com/blog/hiring-frontend-full-stack-components.md
Date: 2021-11-19
Category: Company
Description: Seeking experts in CSS, browser APIs, JS bundling, React, react-native, Swift, Kotlin and Developer Experience

We're trying something new and combining the job description for several frontend roles into a single post. This is meant to highlight the diversity of expertise we're seeking, and to give applicants an idea of how the team will be structured.

**\*Public referral bonus:** Introduce us to a candidate who joins Clerk and we'll send you $5,000\*

## About us

Clerk is a developer tools company in the Authentication and User Management space. We provide developers with full-stack components like [`<SignUp/>`](/components/sign-up), [`<SignIn/>`](/components/sign-in), and [`<UserProfile/>`](/components/user-profile) to handle common but hard-to-get-right flows.

In 2022, we're expanding our scope to include Organization Management and everything that comes with it:

- Organization onboarding
- SAML SSO
- Roles and permissions
- Subscription management
- Authorization

With this new scope, Clerk will provide all the boilerplate necessary to start a B2B SaaS - except the application logic itself.

## Full-stack components?

![Hiring Frontend Full Stack Components guide illustration](./fea05669feec890cc6138436c5b3854371ebfa77-1959x664.svg)

While the last generation of developer tools was characterized by APIs targeted at backend developers, we believe the next generation will be full-stack components targeted at frontend developers.

A component is "full-stack" when it provides UI for end-users to interact with, and when it is powered by a third-party API exposed directly to the frontend. **Critically, frontend developers can implement full-stack components without needing backend developers to plumb data from a backend-only API.**

Besides our own `<SignUp/>`, `<SignIn/>`, and `<UserProfile/>` components, we look at Stripe's recently launched [Payment Element](https://stripe.com/docs/payments/payment-element) as a good example of a full-stack component.

## Who we're looking for

We're looking for developers who can help improve and grow our full-stack component library as Clerk expands into Organization Management. We're seeking expertise across many frontend disciplines:

### HTML & CSS experts

We have our fair share of debates deciding between `grid` and `flex`, but our challenges go much deeper. Customization of our full-stack components is unsolved, and it's our top customer request.

- How can we offer a customization experience that feels natural to developers using any of Tailwind, Bootstrap, CSS modules, or a global stylesheet?
- Should we deploy our components as [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components), iframes, or directly into our customer's DOM?

Help us build a design system whose key feature is blending in with others.

### Browser API experts

Full-stack components are filled with challenges where the solution depends on an intimate understanding of browser APIs.

- How can we allow multiple users to be signed in at once, with different users on different tabs, and *without* URL decoration?
- How can we provide parity between production (same-site to our API) and development (cross-site to our API) environments?
- How can we offer multi-page components if the developer's usage of the History API is abstracted behind React Router or Next.js? Or if they don't use the History API at all?

Puzzles like these are essential to delivering high-quality developer experience, and we need more experts to help us solve them.

### JS bundling experts

There is no Next.js for building full-stack components, so all the challenges of bundling, code-splitting, and lighthouse score impact fall on us. Help us improve our Webpack configuration or choose to rip out Webpack completely.

### React experts

Although our components can be used in any framework (or vanilla JS), they're developed with React behind the scenes. We need more React experts to help us build and optimize them, and we're especially interested in leveraging new tools like React Server Components.

### Mobile experts (react-native, Swift, Kotlin)

Help us port our Javascript core to native app developers. While a few developers have reverse engineered Clerk to support mobile, we’re excited to begin building first-class SDKs for mobile applications.

### Developer Experience experts

Every project at Clerk is focused on improving developer experience. Our key innovation is our frontend-facing API that powers our full-stack components. Instead of authenticating with a secret key that authorizes any action, it authenticates with the user’s session and only authorizes actions the user is permitted to take.

We've found this pattern to be incredibly empowering for frontend developers, who use Clerk to take control of User Management without ever being blocked by backend developers. As we expand into Organization Management, we need help defining the new APIs that will unlock the functionality for the frontend.

## Current stack

Clerks components are written in Typescript using React and CSS modules. They are packaged with tsdx and deployed on npm. The backend is written in Go and Postgres.

## Requirements

- 2+ years of experience in your frontend focus area
- A passion for developer tools and high quality developer experience
- Able to write clean, secure, and performant code with attention to detail
- Able to perform well in a fast-paced, remove environment

## Culture

The team at Clerk is small but our aspirations are big. To drive our mission forward, our culture emphasizes frequent deploys and high quality developer experience, both externally and internally. We recommend reading our [weekly changelog posts](/blog) to get an idea of our pace.

Clerk is a remote team, with timezone concentration in the US and the EU (especially Greece). We believe everyone should work their own hours, but also drive a lot of value from our overlapping hours each day.

## Benefits

- Competitive salary and equity
- Gear of your choice for your home office
- Health, dental, and vision insurance (US)
- Unlimited vacation policy - 25 days recommended per year plus national holidays in your country of residence. Take time when you need it.

## Apply

Even if you don't fit these descriptions exactly, we encourage you to apply if you find these challenges interesting. We look forward to hearing from you!

Please apply [through Workable](https://apply.workable.com/clerk-dev/j/C5BBBAB4AA) or email our cofounder directly at [colin@clerk.dev](mailto:colin@clerk.dev)

---

# Clerk raises $4 million to build the next-gen authentication and user management platform for developers
URL: https://clerk.com/blog/clerk-raises-for-next-gen-auth.md
Date: 2021-07-01
Category: Company
Description: Clerk raised a $4 million seed round led by S28 capital with Andrew Miklas (cofounder, PagerDuty) joining our board.

## Announcing our seed round

Today, we're thrilled to announce that Clerk has raised a $4 million seed round, led by S28 Capital with Andrew Miklas (cofounder, PagerDuty) joining our board. Additional participants include Fathom Capital, Calvin French-Owen and Ilya Volodarksy (cofounders, Segment), Darragh Buckley (first employee, Stripe), Max Stoiber (creator, styled-components).

## The business case

Developers love Clerk because it's fast to set up and maximizes conversion through their Sign Up and Sign In forms. Development speed and conversion rates have become bigger challenges in recent years, as users are demanding more variety in the ways they authenticate.

While privacy-focused users are demanding to create accounts by email, convenience-focused users are demanding "single sign-on" through vendors like Google and Facebook. Subsets of both groups are also security-focused, and are demanding multi-factor authentication.

Creating a cohesive user experience that caters to every group is challenging, and developers often make mistakes that leave their users frustrated or unable to access their accounts. A few examples we commonly see are:

- Disallowing single sign-on for users who originally created their accounts by email
- Allowing single sign-on for users who originally created their accounts by email, but accidentally creating them a second account
- Accidentally reducing multi-factor authentication to single-factor authentication during a "forgot password" flow

Clerk's prebuilt Sign Up and Sign In forms eliminate these mistakes and more. They are built by a team of designers and engineers who focus on maximizing conversion without sacrificing security. If custom designs are preferred, Clerk's API can be used instead to speed up development while still mitigating these errors.

## The path ahead

With this funding, we will focus our efforts on five product areas that are crucial to our customers' success:

1. **Security -** Applications built on Clerk automatically receive critical security features like multi-factor authentication, password breach protection, and device management. We will continue to invest in new protections **for our customers' applications**, as well as begin applying for formal security certifications like SOC-2.
2. **Optimization -** Most businesses simply do not have the resources to focus on optimizing the conversion of their Sign Up and Sign In forms. This is our core competency, and we will continue to analyze our prebuilt components to ensure they are as streamlined as possible.
3. **Customization -** In the months since launch, we've heard a chorus of requests for more customization capabilities in our prebuilt components. More flexibility is on the way, as well as better documentation for creating completely custom user experiences with Clerk's API.
4. **Extensibility -** Another frequent request is the ability to connect user data with other applications. We already deployed webhooks so developers can build connections in-house, and now we will focus on prebuilt connections for common vendors, [starting with Hasura](/docs/integrations/databases/hasura).
5. **Developer Experience -** We launched Clerk with SDKs for React, Next.js, and Express - but beneath those SDKs are language-agnostic REST APIs. The coming months will bring official support for more languages and frameworks.

These five focus areas are driven by the requests of our early adopters, whose enthusiasm and steadfast support made this funding possible. We're excited to continue servicing their needs, and also to welcome the next wave of developers in need of better [tools for authentication and user management](/nextjs-authentication).

## Growing our team

Our team has grown from 2 to 15 in the past eight months, and we're excited to continue that growth across engineering, design, developer advocacy, and more. If you're interested in complex design and engineering problems, or the challenge of creating a ubiquitous developer tool, [come join us](/careers).

With immense gratitude,

Colin and Braden Sidoti\
Cofounders, Clerk

---

# Introducing Clerk: All of user management, not just authentication
URL: https://clerk.com/blog/all-of-user-management-not-just-authentication.md
Date: 2021-01-07
Category: Company
Description: The task came with a sense of helplessness. We knew what "great" looked like, but it was impractical to build all of that functionality.

![--- screenshot](./3537bb21b9137a72b75315872c03b0a97678aef2-2000x914.webp "Google user management")

We thought authentication-as-a-service vendors might ease our pain, but over and over again, we were disappointed by how much extra work was necessary. We never understood why until one friend quipped, *"auth-as-a-service really just solves half of 2-factor auth."*

Then it clicked. **We needed all of user management, not *just* authentication.** And we realized if we could solve this problem, countless others could benefit, too.

Today, we're absolutely thrilled to launch Clerk: **user management as-a-service**. We're solving the whole problem, from frontend to backend, with beautiful UIs and elegant APIs. Our architecture pulls user management out of the way, so developers can focus on what makes their software truly special.

![Today, we're absolutely thrilled to launch Clerk: user management as-a-service. We're solving the whole problem, from frontend to backend, with beautiful UIs and elegant APIs. Our architecture pulls user management out of the way, so developers can focus on what makes their software truly special. screenshot](./a37e8ca7365432384210b4b61e7c11d631148c14-2000x1016.webp "Clerk user management")

Our launch today includes UI components for Sign Up, Sign In, User Profile, and what we're calling the "User Button." They can be mounted directly in your application, or you can redirect users to a Clerk-hosted page on accounts.yourdomain.com.

Best of all, the components will automatically update as our team optimizes their design, develops new features, and adds support for the latest in account security.

While today marks an exciting milestone for Clerk, this is truly just a "minimum viable product." The roadmap ahead will bring many features to better support developers and their end users:

- SDKs for additional languages and frameworks
- Additional OpenID Connect and OAuth providers
- Additional 2-step verification factors like TOTP and WebAuthN
- Session management and revocation in the User Profile
- Team management and enterprise authentication like SAML

Need help with something you don't see listed? [Make a request](https://clerk.com/contact/support).