# Clerk Blog — Page 13

# It's the little things: Three developer experience delights of our Remix authentication package
URL: https://clerk.com/blog/remix-delightful-developer-experiences.md
Date: 2022-04-23
Category: Engineering
Description: We integrate with a lot of React frameworks - here's what we love most about our Remix authentication package

Clerk is building authentication for the **modern web**. That means we don't just offer SDKs for different programming languages (Javascript, Ruby, Go), we offer SDKs for each modern React framework, too. We're proud to have first-class support for Next.js, Redwood, Gatsby, Expo, and – of course – Remix.

For every framework, we challenge ourselves to make Clerk's installation and usage as straightforward as possible. In this post, we highlight two developer experiences of [our Remix authentication package](/solutions/remix-authentication) that we absolutely love.

## 1. getAuth(request)

When handling a server-side request, there's only two theoretical ways developers can retrieve authentication data from Clerk.

First, with a wrapper function like `withAuth()`:

```javascript
const handler = withAuth(async (request) => {
  // withAuth adds the `auth` property to request
  const { auth } = request
})
```

Second, with a direct accessor like `getAuth()`:

```javascript
const handler = async (request) => {
  const auth = await getAuth(request)
}
```

Call us crazy, but we like `getAuth(request)` better. It feels more natural to access the data "just-in-time" instead of configuring it as a wrapper.

Fortunately, Remix enables us to provide this developer experience. After some upfront [configuration in root.tsx](/docs/get-started/remix#initialize-clerk-in-app-root-tsx), developers can use [`getAuth()` in the loaders and actions](/docs/get-started/remix#loaders-and-actions) of any route. It's really easy!

## 2. Splats ($.tsx)

We like to say splats are money.

Name a route $.tsx and it will serve all sub-routes. Clerk relies on this wildcard functionality when developers [mount our components directly in their application](/docs/get-started/remix#using-clerk-components).

Specifically, when a developer mounts `<SignIn/>` on the **/sign-in** route, we actually mount several sub-paths:

- **/sign-in** - to start the process
- **/sign-in/factor-one** - to verify the first factor
- **/sign-in/factor-two** - to verify the second factor
- **/sign-in/verify** - to handle [magic links](/blog/magic-links) clicked in an email

These subpaths are nice because it helps us handle the refresh button. If a user is entering the second factor and they click the refresh button, we don't want them to lose their progress. Storing some state in the URL bar helps us provide the best possible user experience.

We love splats because their fun, intuitive, and easy. Next.js calls the same concept "Optional Catch-all Routes" and has the syntax **/\[\[...slug]].tsx**, which we find a little cumbersome in comparison.

## 3. Edge-by-default

We'd be remiss if we didn't include that Remix runs on the edge by default.

In this case, it's really the absence of code we're showing off. There is no "adding" edge support, it all just works.

This is great because Clerk is optimized for the edge. We include [stateless authentication with JWTs](/features/session-management) in every plan, which are perfect for edge-based applications where georgraphy-bound network requests should be avoided. (Don't worry, our JWTs expire every minute so sessions are still revocable!)

The edge is the future, and we're thankful Remix's defaults will help speed up adoption and the web.

---

# Unicorn or Chameleon? Two strategies for exporting customizable React components
URL: https://clerk.com/blog/exporting-customizable-react-components.md
Date: 2022-04-15
Category: Engineering
Description: React Components are the future of APIs – but how can developer tools companies enable robust customization? We explore two strategies.

Clerk's React library exports [`<SignUp/>`](/components/sign-up), [`<SignIn/>`](/components/sign-in), and [`<UserProfile/>`](/components/user-profile) components. They come styled and fully-featured so developers can focus on building their application:

![Exporting Customizable React Components guide illustration](./3faabd62184abfaa71b1a810d56f82596e3d93ac-2000x1016.png)

Unsurprisingly, this leads to the question: *How can I customize the components to match my brand?*

Whitelabeling software is a famously hard and unsolved problem - it's extremely common to find widgets or portions of websites that have completely different styling.

One example is this chat widget from Alaska Airlines, which shows different form field styling (rounded vs square), different buttons (huge text, not capitalized), and a different font (Arial vs Circular).

![Exporting Customizable React Components guide illustration](./63848098c405f0be95f8a961520e83c4be036f83-2880x1596.png)

This quarter at Clerk, we're revisiting our customization strategy. We want to truly solve this problem with perfect matching styles instead of just "close enough" styles. Internally, we say we're switching from a "unicorn" strategy to a "chameleon" strategy.

While we haven't finalized the chameleon strategy yet, we do have a proof of concept running and are excited about the developer experience it produces.

## Unicorn strategy

![Exporting Customizable React Components guide illustration](./3b751ff2967063abbbfe2320254217991a362204-656x350.png)

Our initial approach to theming is a "unicorn" strategy because we came up with the system ourselves – developers have to learn our specific way of applying styles.

We drew inspiration from others, so you've probably seen something like it before. Developers simply pass a `theme` prop to `<ClerkProvider>` to customize aspects of the design:

```json
{
  "general": {
    "color": "#f1f1f1",
    "backgroundColor": "#f2f2f2",
    "fontColor": "#f3f3f3",
    "fontFamily": "Inter, sans serif",
    "labelFontWeight": "500",
    "padding": "1em",
    "borderRadius": "20px",
    "boxShadow": "0 2px 8px rgba(0, 0, 0, 0.2)"
  },
  "buttons": {
    "fontColor": "#f4f4f4",
    "fontFamily": "Inter, sans serif",
    "fontWeight": "300"
  }
}
```

While this system is great for quickly getting close styles, it suffers in the last mile. There simply aren't enough options to provide developers with the complete customization capabilities they desire.

## Chameleon strategy

![Exporting Customizable React Components guide illustration](./bde3d2490d7628fb2febd01d27101894bfae501c-1000x680.png)

Our next iteration approaches customization with a new mindset. Instead of asking developers to learn our strategy, we will integrate with any strategy they already use.

If you've been around the frontend ecosystem for a while, you know there are *several, very popular* styling systems that all work *completely differently.* Because they're so diverse and we want to blend in with all of them, we call this a "chameleon" strategy.

Let's work through an example to explain how it works.

Consider that one of our components has a "primary button." By default, that button renders to this HTML:

```html
<button class="clerk-button-primary">Action</button>
```

*Note: in this post, we're only focused on styles. We'll discuss customizing the "Action" string in the future.*

To change the style of this button, developers will still pass a `theme` prop, but now the selector will be for this specific element:

```jsx
<SignIn
  theme={{
    primaryButton: customButton,
  }}
/>
```

In this snippet, `customButton` can have one of three values:

1. A string with one or many class names. If passed, the value will replace the default `clerk-button-primary` class.
2. A React component that renders a `<button>` and forwards all props (including children). If passed, the default element will not be rendered at all, and instead the passed component will be rendered.
3. A dictionary that adheres to the `CSSStyleInterface` type. This is for completeness more than anything else. If passed, the value will be forwarded to the `style` prop, and the the default `clerk-button-primary` class will be omitted.

Now, let's see how it works for different styling libraries.

### Tailwind

Simply pass in Tailwind classes as a string:

```jsx
<SignIn
  theme={{
    primaryButton: 'p-4 rounded',
  }}
/>
```

### CSS modules

When a CSS module is imported, the object automatically returns class names. Simply pass it in:

```jsx
import styles from './Styles.css'
;<SignIn
  theme={{
    primaryButton: styles.customButton,
  }}
/>
```

### styled-components

styled-components works by returning a React component that automatically forwards props to a `<button>` element – exactly as specified by Clerk:

```jsx {{ prettier: false }}
const CustomButton = styled.button`
  border-radius: 1rem;
  padding: 1rem;
`

<SignIn
  theme={{
    primaryButton: CustomButton
  }}
/>
```

### Chakra

Chakra also provides React components, but they are modified with props, which makes the setup slightly more complex, but still quite simple:

```jsx
<SignIn
  theme={{
    primaryButton: (props) => <Button size="lg" {...props} />,
  }}
/>
```

Since the chameleon strategy ultimately hooks into HTML and React primitives, we're confident that we can make *every* styling library work with this strategy, not just the four we've listed above.

Thoughts, comments, questions? We're eager for your feedback! Please reach out to [@clerk on X](https://x.com/clerk) or [contact support](https://clerk.com/contact/support).

---

# Just-in-time API requests are replacing webhooks
URL: https://clerk.com/blog/just-in-time-api-requests-are-replacing-webhooks.md
Date: 2022-04-08
Category: Insights
Description: Only 30% of Clerk customers use webhooks to sync user data into their own database. Instead, most skip syncing and use our APIs to retrieve data in real-time.

Clerk is building the next-generation of Authentication and User Management APIs. We offer webhooks so developers can sync user records in their own database, but the majority (70%) don't use them. Instead, they simply don't have a users table at all.

The ability to function without webhooks was a baseline technical requirement for Clerk. We knew our developer experience must be easier than our open source competitors, and we felt (and still feel!) this would be impossible if we required using webhooks. The overhead of spinning up a listener process in development is just too significant.

Ultimately, there is only one way a service like Clerk can eliminate the need for webhooks: **ask developers to request data in real-time instead of syncing data as it changes.**

This isn't a novel idea, but it's rarely considered viable because of two overwhelming developer concerns:

1. **Reliability** - If Clerk's API has downtime, many developers are more comfortable having a copy of user data in their own database. The idea is that they can better degrade the experience with stale data than having no data at all.
2. **Latency** - Loading time is a significant concern for everything from UX to Google Search rankings. If a page cannot be rendered until an external API request completes, overall loading time can be much slower.

Reliability concerns are the number one reason customers use our webhooks today. It's a legitimate concern and a prudent mitigation, but it does take significant engineering resources to consume the webhooks and design a failover to the stale-data experience. We expect that over time – as Clerk grows more stable and mature – the percent of customers who opt for webhooks will decline.

On the other hand, latency concerns are a problem we've been able to address head-on, with a little help from cutting-edge technology and the latest software development trends:

## React moved data-loading to frontend, so we moved our API to the frontend

A major reason real-time API requests raise latency concerns is because APIs are usually only requested from the backend. As a result, two hops are required before data can be accessed:

![Just In Time Api Requests Are Replacing Webhooks setup guide](./f7808741d74b8b8d1dd20e482f79274b2118fe7d-1471x895.png)

When the presentation layer was composed into HTML on the server – as it was in MVC frameworks like Rails – it made a lot of sense for APIs to only be exposed to the backend.

But now this paradigm has changed: **with React, data is loaded and composed directly from the frontend\*:**

![Just In Time Api Requests Are Replacing Webhooks setup guide](./f6f8e78fb270be7e98f6310805f8d56494f066a9-1471x723.png)

Eliminating this extra hop ensures that Clerk data can load just as quickly as the developer's own data, as if it lived directly in the developer's database.

*\*: To be more precise, data is loaded and composed directly from React, which may be running in the frontend or the backend with SSR (server-side rendering). If SSR is being used, accessing Clerk's API directly will reduce development overhead, but will not have significant impact on latency.*

## Edge computing reduced the latency of simple plumbing

Although we'd love to make Clerk's entire API accessible from the frontend, it simply is not possible to do so. In general, we can only return endpoints that the current user has permission to access. This is usually limited to:

- Their own profile information
- Information about the organizations they belong to

For other data – like information about other users – we rely on the developer to authorize the API request on their backend first.

In the past, this authorization step very clearly added a hop. But with the recent rise of distributed "edge" computing, the latency cost of this hop has been drastically reduced.

Since edge compute runs close to users, this authorization hop **can readily be executed in under 15ms**, barely impacting latency!

We already see a significant percentage of our customers leveraging the low latency cost of authorization on the edge, and it's growing as edge resources become more more accessible and widespread. In the past few years (and months!), we've seen significant strides from:

- [Next.js launching Edge Middleware](https://nextjs.org/docs/middleware)
- [Remix loaders and actions running natively on the edge](https://remix.run)
- [Netlify Edge making it easy to run arbitrary code on the edge](https://www.netlify.com/products/edge)
- [Cloudflare Workers making it easy to run arbitrary code on the edge](https://workers.cloudflare.com)

## JWTs enabled sub-millisecond session authentication

Although we've primarily discussed user management so far, a unique differentiator of Clerk is that we also manage sessions. We *love* managing sessions because it helps us build better developer experiences. In particular, knowing which user is currently signed in enables us to offer:

- `useUser()` to retrieve the current user's profile information
- `<UserProfile/>` to render a self-serve user profile for the current user

While managing sessions is helpful for our own product, it's essential that we're also able to inform our customer's backend which user is currently signed in - and quickly!

If developers made just-in-time requests to Clerk's API for session authentication, it would add significant latency to every one of their endpoints. This is unacceptable, so we needed to find another way.

Enter JWTs (JSON Web Tokens): cryptographically signed JSON objects that enable us to secure pass the current user's ID to the developer's backend. To verify the user ID, developers simply need to verify the JWT's signature with their public key (for convenience, we've abstracted this logic away in our SDKs).

Incredibly, JWTs allow developers to perform session authentication in **under 1ms**, so latency is not a concern.

But our favorite part about JWT authentication is that it's not just limited to the developer's backend: **Clerk can also generate custom JWTs to integrate with third-party services!** We offer prebuilt "JWT templates" for several database solutions, including [Supabase](/docs/guides/development/integrations/databases/supabase), [Hasura](/docs/guides/development/integrations/databases/hasura), and [more](/docs/guides/development/integrations/overview).

If a service is not listed among our prebuilt JWT templates, developers can build completely custom JWTs using our editor:

![Just In Time Api Requests Are Replacing Webhooks setup guide](./6cc62685b9e5eb1207b58fceabf881a7e68cdc4f-2036x864.png)

## In summary

While webhooks will always have their place, Clerk has demonstrated that developers are willing and eager to adopt low-latency webhook alternatives *today*.

The strategies outlined here are agnostic, and we believe it's inevitable that more APIs will become frontend accessible and leverage JWTs in the future. We're confident that webhook alternatives will lead to faster API integrations and happier developers, and we're thrilled to sharing our findings.

*Interested in problems like these? [Follow us on X](https://x.com/clerk) for more day-to-day insights, or [check out our openings](https://apply.workable.com/clerk-dev) to help us solve them!*

---

# Introducing Web3 Authentication
URL: https://clerk.com/blog/introducing-web3-authentication.md
Date: 2022-01-21
Category: Engineering
Description: Clerk is saving Web3 developers from the greatest evils of the Web2 platform: cookies, multifactor authentication, and profile enrichment

Clerk is launching our first Web3 authentication factor - Sign in with Metamask!

![Introducing Web3 Authentication guide illustration](./adca3d5c16282cbf8af17d8664bd4bb82d2ece4a-1040x452.png)

This launch is the result of dozens of developer interviews, focused on understanding if and how Clerk can contribute to the Web3 ecosystem.

It didn't take long before we discovered three common challenges that we can help Web3 developers with immediately: securing sessions, multifactor authentication, and profile enrichment.

## Securing Sessions

First and foremost - we found a near ubiquitous challenge around securing sessions. It's a two-part problem:

1. How do you verify a user is owns of a Web3 account?
2. How do you safely create a session to persist the users account information?

### Verifying the owner of a Web3 account

It's easy to *insecurely* determine the Web3 account address of a user visiting your website with Metamask connected, just run the following Javascript:

```javascript
await ethereum.request({ method: 'eth_accounts' })
```

Verifying that the returned address is accurate, however, is significantly more challenging. Developers must ask users to sign a transaction, which is a process that undergone several protocol revisions and is hard to keep up with.

This is where Clerk steps in - all the work of signing a transaction and verifying the signature is abstracted away, and wrapped in a `<SignInWithMetamask/>` button.

### Persisting a session

Let's be honest - persisting a session isn't a Web3 challenge at all, but it is one that Web3 developers must endure by virtue of operating in Web2 browsers.

We know Web3 developers don't want to think about things like httpOnly cookies, XSS attacks, and session revocation. Web2 developers don't either, and that's why built-in [session management](/features/session-management) is the foundation of every authentication product at Clerk. We use stateless JWTs that enable authentication in under 1 millisecond, and revocation in under 1 minute. We follow all the best practices so you can focus on building your application.

## Multifactor authentication

Sign in with Metamask uses the same abstraction as our other authentication factors like passwords or [magic links](/blog/magic-links).

Because of this, Clerk's [multifactor authentication](/features/multifactor-authentication) works with Metamask users out-of-the-box. Users simply need to navigate to their user profile and opt-in to multifactor authentication. There's no extra work for the developer beyond mounting a [`<UserProfile/>`](/docs/components/user/user-profile) component, or redirecting to the Clerk-hosted component.

## Profile enrichment

Off-chain profile enrichment is a topic of much debate in the Web3 community. Ideally, data like email addresses and phone numbers could be retrieved on-chain following the principles of [self sovereign identity](https://en.wikipedia.org/wiki/Self-sovereign_identity).

But as of today, there are no standard protocols for retrieving this data. As a result, top Web3 companies like OpenSea still collect and verify email addresses off-chain.

Clerk enables developers to easily do the same. We provide simple helpers for collecting and verifying phone numbers, email addresses, and even OAuth accounts. Beyond that, we accept structured data likes names and profile photos, as well as provide a generic metadata field for bespoke profile enrichment.

In the future, we look forward to enriching profiles in a more decentralized manner. Today, we hope this mechanism can help bridge the gap from Web2 to Web3.

## Try it out!

[Try out our guide for installing Web3 authentication.](/docs/users/web3-wallets) The guide will get you started with a new Next.js application with Metamask authentication.

## Future roadmap

This launch is the first of many upcoming Web3 launches. Our rough roadmap ahead includes:

- **Sign in with Ethereum** - we know that Metamask alone is a little limiting and will add generic Ethereum support soon
- **Authorization via Token Gating** - In the Web2 realm, our team is actively building authorization via Roles and Permissions. We see many corollaries to Web3 authorization via token gating are approaching the primitives in a way that will support both.
- **Multi-chain support** - Because we fully anticipate a multi-chain future

Need something we didn't mention? Please reach out through any of our [support channels](https://clerk.com/contact/support) - we're still defining this roadmap and very interested to hear how we can better meet your needs.

---

# How to compete and WIN in a software economy [Part 2]
URL: https://clerk.com/blog/how-to-complete-and-win-in-software-economy-2.md
Date: 2022-01-13
Category: Insights
Description: In this next part, we'll discuss how to identify 'core' vs. 'non-core' development & how thoughtful outsourcing can be used to develop process power.

[In the previous part of this article](/blog/how-to-complete-and-win-in-software-economy), the discussion centered around the importance of increasing product velocity, especially in today’s software-centric environment. The section concluded with the idea that you should ‘focus on your core and outsource non-core services’.

Although outsourcing non-core development \[via developer tools, i.e. infrastructure services] is clearly essential to increasing product velocity, understanding *how* to determine if something is non-core development is often less clear. Accordingly, in this next part, we'll discuss how to identify 'core' vs. 'non-core' development, and how thoughtful outsourcing can be used to develop [process power](https://www.nfx.com/post/seven-powers).

First, let’s look at how one determines which elements are core or non-core to a business. Instead of proposing my own methodology I’ll instead lean on someone with more perspective and experience, and return to Jeetu Patel (referenced in part 1).

The excerpt below is from his [techcrunch article](https://techcrunch.com/2016/06/07/software-is-eating-the-world-5-years-later), where he provides a framework for designating an element ‘non-core’, by asking three questions: Will the service provide your application an innovation tailwind? Can the service be substituted by another supplier? Will the service provide a neutral to incremental experience improvement for my customers?

> 1. Will the \[non-core] service provide your application an innovation tailwind? This could happen for several reasons, such as the sheer innovation velocity by the specialist supplier in a highly competitive market where your company benefits by shelling out only a fraction of the cost. If an innovation tailwind occurs, then use specialists who provide such a service. For example, by using the payments stack from [Braintree](https://www.crunchbase.com/organization/braintree-payment-solutions), Uber is able to benefit on all the payments advancements made by Braintree on their platform.

> 2. Can the service be substituted by another supplier? By definition, the ability to swap the service means it doesn’t warrant it to be your core competency. Uber switching between Google Maps and [Mapbox](https://www.crunchbase.com/organization/mapbox), for example.

> 3. Will the service provide a neutral to incremental experience improvement for my customers? Most importantly, even if the answer is that its impact is neutral (the experience the specialist provides is just as good as the one you would’ve been able to provide had you built the service yourself), it makes little sense to keep doing it yourself.

The first question - Will the service provide your application an innovation tailwind? - is often the only question product owners (e.g. developers, PMs, founders) ask, because you get the best of all worlds. Not only does consuming these types of services improve your product indirectly, by allowing you to offload a non-core element \[and focus on differentiators], but they also directly improve your product due to their own product velocity. This speed of innovation also makes the decision more obvious for product owners, as it’s clear to them that they are not going to build something better internally (at least not on any reasonable timeline).

The second question - Can the service be substituted by another supplier? - is considered less often, but is usually applied in practice consciously or unconsciously. Unconsciously because if there is a clear market for a certain service, it implies that there are already many buyers, and since people generally just follow the crowd, they believe they should just buy \[as opposed to a build] as well. Consciously, if there are multiple services that can be interchanged, then using a service here would create optionality. You can quickly get the product element you need up and working with a service, and if for any reason your business needs change you can easily replace it. Whereas, if something built in-house doesn’t work well, it can manifest in much greater loss aversion - a logical fallacy which results in an unnecessary waste of resources. Additionally, If you can swap services, then that market is already fairly well defined and is likely becoming commoditized, and rebuilding a well-defined commodity product doesn’t make good sense.

Ultimately, the driving force behind innovation and commoditization is competition, and in competitive markets, innovation is driven up and/or cost is driven down, and it’s relatively easy to understand how you benefit from this dynamic. Understanding these two questions and applying them to every product decision will get you far, but to fully benefit from outsourcing, applying the last question - Will the service provide a neutral to incremental experience improvement for my customers? - is critical.

This third question is the one that product owners rarely ask, but is key to developing a competitive advantage around product velocity. Essentially, the question prompts you to outsource any element that would not have a negative impact on user experience. This is the question that unlocks outsourcing, and drives the highest degree of focus to the few items that will truly differentiate your business. We’ll revisit this last question later.

For now, let’s touch on how to turn this question framework into a durable competitive advantage. Returning to Geoff Charles who we referenced in part 1, “Simply put, having the best product is not a competitive advantage. Everything can, and will, be bested. Having the best product development velocity and culture is what it’s all about.”

Importantly, the key here is to build a process around these three questions – staying abreast of developer tool innovations, regularly reviewing/reevaluating core vs non-core services, and then, fully leveraging dev tools where appropriate. Creating a process around this allows you to consistently maintain an advantage over time, and consistency over time is what generates true power.

Specifically, the ability to consistently maintain faster product velocity relative to competition, while also decreasing (or at least, without increasing) the cost of development is what [Hamilton Helmer](https://www.linkedin.com/in/hamilton-helmer-42983) calls process power - an embedded company organization and activity sets which enable lower costs and/or a superior product - which confers a massive advantage.

Helmer notes that the major barrier to developing process power is hysteresis - the phenomenon in which outputs significantly lag inputs. In this kind of system the inputs must be sustained, in order for the resulting output to become realized.

Returning to the framework we outlined earlier, this is another reason why question #2, and especially #3 are harder to grok. In the first case, where you adopt a highly innovative product there is usually an immediate and understandable short-term benefit (no lag in output). In the second case, much of the benefit comes from the creation of optionality, which is less obvious, but still fairly evident, since the benefits of optionality can come into play at any time (short, medium, or long term). In the third case, the benefits of increased focus and a reduction in technical debt and maintenance are longer-term and compound over many years. This hysteresis is what makes question #3 non-obvious, and since your peers are likely not thinking about outsourcing to this degree, it’s also what makes it a potential competitive advantage that can be sustained.

In summary, you should outsource an element if the service: is as good as (or better than) what you would have built yourself, can be substituted for another, or provides an innovation tailwind. And most importantly, by turning this 3-question framework into a process that is regularly applied to product decisions, over time you can develop process power.

---

# How to compete and WIN in a software economy [Part 1]
URL: https://clerk.com/blog/how-to-complete-and-win-in-software-economy.md
Date: 2022-01-11
Category: Insights
Description: Software has eaten the world and almost every business is a software business. How do you develop a competitive advantage and win in today's software economy?

> *As a disclaimer, the strategy outlined in this article is necessary, but not sufficient. There are still other things that have to go right in your business and other ways to develop competitive advantages, but this strategy will significantly move the needle for any businesses. It will also help you develop these additional advantages (more quickly).*

If it wasn’t already obvious, we are now in a software economy. [10 years ago, software *was* eating the world](https://www.wsj.com/articles/SB10001424053111903480904576512250915629460); today, software has clearly eaten the world, and almost every business is a software business (at the very least, highly enabled by software) or has been bought by a software business.

It's no longer Netflix vs. Blockbuster or Uber vs. taxis. Now, it's Netflix vs. Disney+ vs. HBO Max vs. Hulu, and Uber vs. Lyft vs. Juno vs. micro-mobility (scooters, bikes, etc.) ... not to mention the 100+ other software startups vying for a piece of each of these markets.

And there is no sign of stopping. There are more startups, venture investors, and venture dollars than ever before. Sure, it may not be a perfectly smooth curve forever (there could be another [SaaSacre](https://kellblog.com/tag/saasacre), the web3 bubble could burst any moment, and the metaverse may only ever exist in [books](https://en.wikipedia.org/wiki/Snow_Crash)), but at this point, even a serious correction would be a metaphorical bump in the digital road.

Assuming we agree that we are in a software economy, then we can also agree that simply leveraging software is no longer a differentiator or competitive advantage.

In the previous paradigm of 10 years ago, simply building decent software was enough. The power of software relative to a manual or non-digital process was so massive that even mediocre software enabled huge leverage for an end customer and beat out other possible solutions. Processes enabled with C+ software (no pun intended) beats A+ non-digital processes almost every time. Today, the playing field is more even. Sure, there are still opportunities to digitally transform antiquated products and industries, but these are becoming more and more rare, and no longer representative of a typical competitive landscape.

So, how do you develop a competitive advantage and win in a *software* economy?

If we revert to Marc, the man who proclaimed software is eating the world in the first place, he would likely tell you: “[Cycle time compression may be the most underestimated force in determining winners and losers in tech](https://a16z.com/2014/06/03/pmarca-tweetstorm-cycle-time-determines-winners-and-losers-in-tech).”

And most of the venture community would agree. For example, here's a similar thought from Sunil Dhaliwal, GP at Amplify Partners, "[Product velocity is a reliable signal for early-stage companies that end up winning. Ship regularly. Ship quickly. Constantly improve.](https://twitter.com/dhaliwas/status/1445870724594372610)"

Importantly, operators are aligned with investors on this. Geoff Charles, Head of Product at Ramp, writes: “[In today’s startup environment, speed is everything. It’s not just about building things faster, it’s about decreasing the cycle time of learning and reducing the cost of being wrong](https://geoffcharles.medium.com/how-to-increase-product-velocity-8d0979a67c22).” Ok great, makes sense: increasing product velocity allows you to get more features out the door (or iterate on features faster) relative to your competitors. Additionally, moving faster than your competitors confers further benefits, such as being able to take more risks (i.e. be more innovative), since the cost of doing something new is lower. Oh and let’s not forget that [being fast is fun](https://jsomers.net/blog/speed-matters) \[for more thoughts on this, see [Speed Matters](https://jsomers.net/blog/speed-matters) by [James Somers](https://twitter.com/jsomers), which Charles references in his article].

Now the next question is, how do you increase product velocity?

Before examining how to increase product velocity specifically, let’s take a step back and think about how one increases productivity generally. A counter intuitive, but a common piece of advice is to ‘do more, by doing less’. [Google this phrase](https://www.google.com/search?q=do+more+by+doing+less\&rlz=1C5CHFA_enUS937US942\&oq=do+more+by+doing+le\&aqs=chrome.0.0i512j69i57j0i22i30l3j0i390l2.3000j0j9\&sourceid=chrome\&ie=UTF-8), and you’ll get a series of articles from HBS to Forbes explaining why this is. In essence, by taking on fewer things, you can dramatically increase your effort, and more importantly, your focus on each one. Thus, narrowing your focus and saying ‘no’ to things that are not at the top of the priority stack, allows you to accomplish more without actually increasing net effort or focus. Now, let’s apply this to software development. By narrowing the product focus to items that truly move the needle for one’s business and differentiate them in the market (i.e. ‘core development’), development productivity, and thus product velocity, is increased without increasing costs. As Steve Jobs famously said, “[Deciding what not to do is just as important as deciding what to do](https://www.quora.com/What-do-you-think-of-Steve-Jobss-quote-deciding-what-not-to-do-is-as-important-as-deciding-what-to-do).”

However, many of the items which you say ‘no’ to still need to get done. Filing your taxes doesn’t make you better at making money, but it still needs to be done. In these cases, we outsource this work \[to a CPA or software service like turbotax]. The same methodology should be followed in software development.

As [Jeetu Patel](https://techcrunch.com/author/jeetu-patel), Board Member at [HackerRank](https://www.linkedin.com/company/hackerrank) and Chief Product & Strategy Officer at Box, puts it, "[focus on your core, and outsource non-core services… Focusing on your core when it comes to technology makes it easier to focus on your end-customer experience — and that’s what makes a great software company.](https://techcrunch.com/2016/06/07/software-is-eating-the-world-5-years-later)”

As Jeetu elaborates further in the article, outsourcing in software is done via developer tools \[i.e. infrastructure as a service that provide the same or better functionality as what you could build in-house]. And that’s how you compete and win in a software economy.

*[In the next part of this article](/blog/how-to-complete-and-win-in-software-economy-2), we'll discuss how to identify 'core' vs. 'non-core' development & how thoughtful outsourcing can be used to develop [process power](https://www.nfx.com/post/seven-powers).*

---

# The Ultimate Guide To JSON Web Tokens (JWTs) and Token-Based Authentication
URL: https://clerk.com/blog/guide-JWT-authentication-JSON-Web-Tokens.md
Date: 2022-01-07
Category: Insights
Description: JSON Web Tokens, more commonly known as JWTs, are encoded and cryptographically signed data that allows for the secure transfer of information.

Security has become a primary concern in today's digital world. With almost every business process going digital, individuals and businesses must ensure fool-proof security and keep their data safe. Not just their information — they also need to protect their clients' data from any digital fraud. That's where JavaScript object notation (JSON) web tokens (JWTs) and JWT token authentication come in handy.

JWT is a compact and URL-safe way of transferring claims or information between two parties. The JWT authentication method makes sure that the information reaches the party it was intended for.

If you want to know all the ins and outs of this token-based authentication method, keep reading to find out how it works, what a JWT token is, its benefits, and much more.

## **Understanding User Authentication**

User authentication allows a device to authenticate the identity of someone trying to connect to a network. Typically, it requires the user to sign-up with a unique ID and password, which they can use to sign in later. This way, the computer recognizes the user and lets them in after the authentication process instead of asking "who are you?" every time they sign in.

Simply speaking, the user authentication process allows a user to access their account while blocking all the unauthenticated entries from the same account. The user's ID and password serve as their identity.

When your system's user authentication process isn't secure, it increases the chances of cybercriminals breaching into your system and reaching essential data.

### **Types of Authentication**

To access any network, the user needs to provide the information secured between the network's server and the user, such as a pin, code, or password. This information is referred to as an authentication factor. There are several ways a server ensures user authentication, including the following.

#### **Multi-Factor Authentication**

A multi-factor authentication method verifies users' identities via multiple authentication methods. For example, when users enter their ID and password, they won't access the resources directly. Instead, they must verify themselves via a one-time link or a security code sent to them through text messages or emails.

The multi-factor authentication strategy ensures multiple layers of protection over the user's account and private data. Even if a hacker determines any users' ID and password, they also have to go through additional authentication methods — or else, they will be denied access.

#### **API Authentication and API Tokens**

Application programming interface (API) authentication is the process of verifying the identity of users trying to get access to the resources on a server. The authentication process includes the use of API tokens.

API tokens are sort of a unique identity of a user or an application trying to access a service. When an application wants to access a service, it generates an API token for the application that it can use when requesting that particular service. Later, when the application makes an access request, the service matches the token provided by the app to the one it had stored to authenticate.

Simply put, an API token works just like a username and password combination. However, the API tokens provide a second layer of security, and the users have substantial control over each action and transaction.

#### **Token-Based Authentication**

Token-based authentication is a process that allows a user to verify their identity through a unique access token. As long as the token remains valid, the user can access the website or app from which they received the token. They don’t need to re-enter their credentials, meaning their username and password, each time they try to access the same website or app.

The signed tokens are just like stamped tickets.

## **What Are JSON Web Tokens (JWTs)?**

The compact method of JWTs is an open standard for the safe transmission of information — encoded as a JSON object — between two or more parties.

For example, if you want to sign in to Tinder with your Facebook profile, Tinder will contact Facebook's Authentication server and ask for your username and password. As soon as Facebook's server verifies your credentials — your username and password — a JWT will be created and sent to you. Tinder gets this JWT and allows you to access its services.

### **What To Know About Token-Based Authentication**

Token-based authentication is a process that ensures the security of applications by using signed tokens as a form of verification.

Tokens, like JWTs, eliminate the need for contacting any third-party service for the authentication process. Instead, the server performs the verification by looking at the signed tokens.

The JWTs carry a special message authentication code (MAC) that confirms the authenticity of their contained claims.

JWTs are either signed using a special HMAC algorithm or a private and public key pair. This key pair ensures the protection of the claim or information.

### **Token Expiration**

When a user receives an access token, it comes with details about a refresh token and an expiration time. For example:

```
{
  "access_token": "AYjcyMzY3ZDhiNmJkNTY",
  "refresh_token": "RjY2NjM5NzA2OWJjuE7c",
  "token_type": "bearer",
  "expires": 3600
  }
```

The refresh token means that the access token has a defined expiration period, and the user will get a new one.

The "expires" number is the number of seconds for which the access token will be valid. Usually, it's the service that specifies the token expiration period.

If you're using a JSON-based API and the token has expired already, you will likely get a JSON error response with the `invalid_token` error.

```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token"
  error_description="The access token expired"
Content-type: application/JSON

{
  "error": "invalid_token",
  "error"_description": "The access token expired"
}
```

When your code identifies this error, it initiates a request to the token endpoint by using the refresh token it received before and will obtain a new access token that it can use to make the original request again.

## **JSON Web Token Structure**

JWTs consist of three parts: header, payload, and signature. A dot (.) is used between each part to differentiate it from the other. The structure looks like this: Header.Payload.Signature. Let's break down each of them in detail.

### **Token Header**

The header is divided into two parts: the token's type (JWT) and the hashing or signed algorithm used (HMAC SHA256 or RSA).

The JSON is Base64Url encoded to form the header.

### **Token Payload**

The payload is the part where the actual claim or information is stored. Claims are divided into three types: registered, public, and private.

#### **Registered Claims**

These are a set of claims which are pre-defined and not mandatory, but they are recommended to provide useful claims, including:

- exp (expiration time)
- iss (issuer)
- sub (subject)
- aud (audience)

Since JWTs need to be compact, the size of a registered claim is only three characters long.

#### **Public Claims**

The users can define public claims and are open for public consumption. But these claims can cause collisions with other names. To avoid such name clashes, the JWT user must define public claims in the [IANA JSON Web Token Registry](https://www.iana.org/assignments/jwt/jwt.xhtml) before using them.

#### **Private Claims**

Private claims are customized claims shared between two or more parties that agree on using them mutually. These claims are neither registered nor public.

### **Token Signature**

The token signature ensures the authenticity of a message that it didn’t get changed before reaching its destination. The private key ensures the privacy of a token it is signed with. These keys can also verify the sender of the JWT.

A signature consists of:

- The encoded header
- The encoded payload
- A secret
- The header's algorithm (HMAC SHA256)

## **How Do JWTs Work?**

A JSON Web Token is returned in authentication when the user succeeds in signing in with their credentials. It's recommended that users not keep tokens for an extended period as it can pose severe security issues.

Whenever the user intends to access a protected server, they need to send the JWT, generally in the Authorization header, with the help of the Bearer schema. The Bearer schema or Bearer authentication is an HTTP authentication scheme that includes security tokens called bearer tokens. The name "Bearer authentication" actually refers to "give access to the bearer of this token."

The Authorization Bearer header looks like this:

```
Authorization: Bearer <token>
```

In some cases, this step can be a stateless authorization method. The server's routes will evaluate whether the JWT is valid in the Authorization header. If the route identifies a valid JWT, the user will access the protected resources.

CORS is a browser mechanism that allows access to resources outside a specific domain. To ensure security, many browsers prohibit cross-origin HTTP requests. When the token is sent in the Authorization header, cross-origin resource sharing (CORS) is no longer a problem since it doesn't use user credentials, such as cookies, on requests.

## **How Can JWTs Be Used?**

JWT should be used for API or user authentication and server-to-server or user authorization.

### **User Authentication**

User authentication is the process that involves the verification of the user. It ensures that the user is the same person they claim to be.

At this step, the user needs to validate their credentials through providing ID or passwords, answering security questions, or using facial recognition. User authentication is generally performed before user authorization.

### **User Authorization**

It is the process that involves the verification of the resources the user can or cannot access. This step comes after user authentication, where the user is granted access to certain resources based on policies and rules.

## **The Benefits of JWTs**

The use of tokens, especially JWTs, has many benefits.

### **Increased User Security**

JWTs ensure fool-proof user security. These tokens use a public and private key pair for a double layer of protection and provide users with an improved authentication experience.

Moreover, both signed and encrypted JWTs ensure the integrity of the claims. They also carry a special MAC that makes sure that the claim or information isn't changed before reaching the destination.

### **Compact and Self-Contained**

The JWT is a compact and self-contained token that has all the authentication information, expiration time, and other pre-defined claims signed digitally.

## **Security Risks and Security Issues With JWTs**

The JSON Web Token is a secure way of transmitting information, but this doesn't mean that it won't have any security risks. Some security risks and issues with JWTs are the following.

### **Problems in Verifying the Signature**

Most JWT libraries offer one method for the decoding and the other for the verification:

- **decode():** It doesn't verify the signature but decodes the token from base64url encoding.
- **verify():** It verifies the signature as well as decodes the token.

Often, developers mix up these two methods, and the signature doesn't get verified. This means the application can now accept any type of token in a valid format. In addition, some developers may also forget to enable signature verification. Such things can make the token vulnerable to security breaches.

### **Allowing the None Algorithm**

JWTs accept different types of algorithms, such as RSA or HMAC, to create a signature. However, it also allows the None algorithm, which refers to an un-signed token.

When JWTs permit this algorithm, the user can easily pass through the signature checking by changing an existing algorithm to None. When this happens, the hacker can smoothly replace the valid algorithm and remove the signature.

## **JSON Web Tokens vs. Simple Web Tokens (SWTs)**

When JSON is encoded, its size becomes way smaller than XML. This makes JWTs more compact and precise than security assertion markup language (SAML) tokens and SWTs. Apart from that, the compact size of JWTs also helps them pass in HTML and HTTP environments easily.

When it comes to security, SWTs only use a single key. JWTs use a public and private key pair, primarily an X.509 certificate, for improved authentication. In addition, signing JSON is way simpler than signing XML. JSON parsers are also used more in most programming languages as they have a document-to-object mapping, which others fail to offer. Usage-wise, JWTs can be easily used on multiple devices, such as mobiles and laptops.

All of this makes JSON web tokens easier to work with across various platforms.

## **JWT-Based Authentication Summarized**

All in all, JWT-based authentication is an excellent and secure way of transmitting information between multiple entities. The signatures on JWTs ensure the protection of the claims or information. All the user has to do is remember the correct key. Apart from that, JWTs are easier to understand and more compact than other web tokens like SAML or SWTs.

JWTs are also used at the internet scale, making them easier to process on a wide range of devices. However, it also poses some security vulnerabilities, like allowing the None algorithm and passing an unsigned and unverified token. If you want a better option, you can opt for a [session management software](/features/session-management) that manages your session's lifecycle and authentication requests on its own.

---

# 2021: The Year Authentication Saw a Resurgence (and Why)
URL: https://clerk.com/blog/2021-the-resurgence-of-authentication.md
Date: 2021-12-31
Category: Insights
Description: 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.

## The Modern Web needs a new solution

Authentication for old **M**odel **V**iew **C**ontroller 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](https://hasura.io) and [Supabase](https://supabase.com). 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](https://hasura.io/docs/latest/auth/authorization/quickstart) and [Row-Level Security](https://supabase.com/docs/guides/auth/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](/nextjs-authentication), [Hasura](/docs/integrations/databases/hasura), and [Supabase](/docs/integrations/databases/supabase), as well as other Modern Web frameworks like [Expo](/expo-authentication) and [Gatsby](/docs/quickstarts/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"](/features/social-sso) 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](/blog/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/>`](/components/sign-up) and [`<SignIn/>`](/components/sign-in) 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.

---

# Consider dropping your users table
URL: https://clerk.com/blog/offload_user_table.md
Date: 2021-12-01
Category: Insights
Description: The same way we would rather let Stripe handle your credit card, we'll let Clerk handle your phone numbers, emails and sessions.

In 2021, all of the computers are on a cloud and [developer experience matters at least as much as database internals](https://planetscale.com/blog/nonesql-all-the-devex). We can choose more and more of our tech stacks [omakase](https://dhh.dk/2012/rails-is-omakase.html), and use the right tools for the right jobs. At phonetoroam we combine ruby on rails and a postgres database with [user management as a service from Clerk](/). This gives us the power of ruby and rails to create a well-tested, flexible API to receive and process messages, while harnessing experts to deal with user management. Using a dedicated service for all of our user management has a few benefits:

- We don't have to store sensitive user data in the same severs as your messages now. The same way we would rather let Stripe handle your credit card, we'll let Clerk handle your phone numbers, emails and sessions. Clerk spends spends all day thinking about how to securely store user credentials, and will continue to keep them secure over time.
- Our user experience for adding and verifying phone numbers is now better. In the same way that Stripe is really good at making forms to handle credit cards, Clerk is really good at making user management forms.
- Our user management is domain wide now. We can now launch serverless [Jamstack](https://www.gatsbyjs.com/docs/glossary/jamstack) sites with full user authentication on any subdomain.

Thoughtful orchestration of cloud infrastructure allows us to center our code around the problems we're seeking to solve, and delete the rest.

We recently refactored our rails app to use Clerk for user management, and have a few tips to share:

- This type of refactor will get more complex over time — the complexity of a User object is likely super-linear because it cuts horizontally through (an increasing number of) other models — so get buy in as quickly as possible
- If you have a hodgepodge of user analytics code, clean it up before this refactor. You will likely move most of your signup related analytics to a webhook receiver. If you are using ruby/rails, one service object to wrap your analytics provider (mixpanel or segment work well) should do the job. If that service is well tested, it is relatively easy to move it around.
- The end goal of the refactor will be to delete your User model and drop your users table, so a good first step is to make your User model as small and condition-less as possible. This will make the surface area of your refactor smaller.
- The refactor will still be relatively large (our small rails app was about +1500/-2500 lines over \~50 files), so you need the code confidence and [engineering maturity](https://en.wikipedia.org/wiki/Capability_Maturity_Model) to make such a change. We recommend high unit test coverage, some level of integration tests, and/or a well thought-out, strongly-typed system.
- The migration itself will comprise of replacing most references to a user with a `clerk_id`, and wrapping some API calls to Clerk in a service object. Clerk provides a writable JSON object they call `private_metadata`, which can be used as a key/value store for state about a user.

*This article has been republished. You can [find the original post on the phonetoroam website](https://www.phonetoroam.com/blog/why-and-how-to-drop-your-users-table).*

---

# Trading Experts | Case Study
URL: https://clerk.com/blog/trading-experts.md
Date: 2021-11-20
Category: Insights
Description: A case study of how Trading Experts used Clerk to quickly implement the authentication and user management features they needed.

*“I was super impressed. I thought I was just going to build a very basic email/password flow using something open source — knowing that I'd have to deal with issues my customers face down the line. With Clerk, I was able to give my users passwordless auth, seamless UIs, and a complete user profile in much less time than it would have taken to go the open source route. The free MFA was just icing, and some of our users have opted-in to it."*

*- Ben Zamani, Founder of Trading Experts*

## About Trading Experts

Trading Experts is an online financial education and training platform, founded by Ben Zamani and Shake Pryzby. Combined, they have over a decade of experience working at investment banks and proprietary trading firms on Wall St. Through their website and mobile app, they offer training and consultations, host an online chat community, and provide real time alerts and tips to their premium members.

## Tech Stack

- Frontend: Next.js and Swift
- Backend: Golang / Postgres, hosted on Render

## Before Clerk

When Trading Experts first started, the user management functionality was extremely basic. There was no user profile, and user management was managed manually. Password-change requests were common, as was people struggling to access their account. Resolving these issues was time consuming, and very manual for the Trading Experts team.

*“There was a laundry list of improvements that were needed and new features to build, we knew authentication was an issue, but it seemed like such a pain for what we needed... I’d used and struggled with Auth0 before, and didn't want to deal with that again. I really wanted something that 'just worked', and was easy to setup for both our web and mobile app.” - Ben*

As Ben started his new NextJS web app, and iOS app, he didn't want to embark on the couple week project to setup all of the "boilerplate" user management code using either Auth0 or an open source solution. He also needed a way to unify authentication across both platforms, as well as a number of 3rd party services.

That's when he found Clerk, and thought it would fit his needs.

## After Clerk

Trading Experts was able to remove a lot of the old auth-related backend code, and even their 'Users' table, deciding to leverage Clerk's metadata fields for simplicity. They store Stripe IDs for billing, Device IDs and tokens for push notifications, and subscription information in the appropriate user metadata fields.

Trading Experts eliminated 100% of user account issues (a number we're quite proud of at Clerk!) - receiving no forgot password requests, and no account access complaints since the release date. Instead of manually editing their database and using some adhoc scripts, Trading Experts now uses Clerk’s out-of-the-box admin panel to easily change subscription information for their users as needed. These 2 features have dramatically reduced the amount of support needed to maintain their user base, and their apps.

*“I didn't think it could be as easy as it was. I'm looking forward to Clerk's integrations, so I can remove our payments and push notification code, and actually have a source of truth for our user data. They need to hurry up with that!” - Ben*

---

# 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)

---

# The Ultimate Guide to BCrypt and Authentication Protocols
URL: https://clerk.com/blog/bcrypt-hashing-authentication-encryption.md
Date: 2021-11-02
Category: Insights
Description: Learn why bcrypt is the industry standard hashing algorithm for authentication - including its history and how it compares to other protocols. 

Digital security becomes more critical every day. As financial accounts and other sensitive data continues to move online, it’s vital for companies to keep their clients’ information safe. It’s not enough to simply provide password protected accounts. Those passwords must also be stored safely and effectively.

That’s where bcrypt becomes important. [Bcrypt](https://www.npmjs.com/package/bcrypt) is an algorithm designed to hash and salt passwords for safe storage. It’s an industry standard that’s time-tested and proven to resist threats from hackers and other malicious agents. Keep reading to learn the fundamentals of bcrypt, why it’s so effective, and how it compares to different password protection algorithms.

## **What is hashing?**

Hashing is a critical first step in the password storage process. Programs use hashing to condense data of a random size into a fixed size. Essentially, the program uses a mathematical formula to take an arbitrarily long text or data input and convert it into a hash. Hash algorithms apply a procedure to the input many times to obscure the original data.

The hash itself is a series of letters and numbers that will always be the same length. For example, a 10 character input and a 40 character input might be stored as 16 character hashes.

It’s important to note that this process can lead to multiple strings generating identical hashes. Since the process converts all input into strings of identical length, it’s inevitable that some will be the same. Usually, this is fine, but it can lead to vulnerabilities. For example, if too many inputs lead to identical strings, then it’s easier for hackers to brute-force their way into users’ accounts. There are more potential random inputs the hacker could guess that would lead to the hash matching.

Good hashing programs must meet a few qualifications:

- A specific input will *always* generate the same output
- Modifying an input will change the resulting output
- Different inputs should usually provide different outputs

Hashing can be applied to data of any kind, but it’s particularly useful for passwords. The hashing process is a one-way conversion. Once data has been hashed, it’s essentially impossible to unhash or reverse the process to come up with the original input. This property reduces the risk of leaks or attacks and makes hashed passwords safe to store.

Furthermore, since a specific input will always provide a specific output, a hashed password will always match the stored hash. The program will take the user’s input password, run it through the hash function, and compare it to the hash connected to their account. If they match, the user has entered the correct password and is allowed to access their account.

## **Hashing vs. encryption**

Hashing is different from encryption, another method of storing passwords and sensitive information. When information is encrypted, it can be unencrypted with the right program and encryption key. The encryption process is a two-way street, while hashing only goes one way.

Since encryption can be reversed, it can serve a wider variety of use-cases, but it’s less secure than hashing. A hashed password can’t be converted back into the plaintext input, but encrypted passwords can. If a hacker can steal the encryption key, then the plaintext input is theirs.

## **Limitations to hashing**

Of course, hashing alone isn’t a perfect solution. It has a few limitations that prevent it from solving all password storage problems up front. These weaknesses include:

### **Brute force attacks**

Brute force attacks are a significant problem for sites that rely entirely on hashing. These attacks are performed by trying many different passwords with a particular username until one of them finally works. It’s considered a “brute force” attack because there’s no actual attempt to figure out the user’s password. The hacker is just using a program to guess many different passwords very quickly until one matches the hash.

Without other security methods, brute force attacks will eventually work — it’s just a matter of time and computing power. And if a hacker uses a list of common passwords first, they will likely be able to log into a large number of the users’ accounts with little effort in a short amount of time.

### **Rainbow table attacks**

A rainbow table attack is more sophisticated. This method doesn’t bother with figuring out the actual password; it focuses on finding text that will produce the correct hash.

The rainbow table is a collection of common passwords and the hashes they generate under specific circumstances. If a hacker can access the stored hashes against which the authentication technology checks hashed password input, they can use the rainbow table to look up the resulting hash. If the hash is on the table, they can simply input the associated plaintext password and log in to the user’s account.

### **Collision and pre-image attacks**

“Collisions” are different inputs that both result in the same hash. If a hacker can find a fake password that generates the same hash as an actual password, it works just as effectively against a hashed database. Collision attacks focus on finding *any* strings that generate identical hashes and then look for hashes that match what they’ve generated. These attacks work best if the hacker has uncovered a large number of password hashes — they have more hashed passwords they can potentially match.

For example, in the [now-outdated hashing program MD5](https://www.mscs.dal.ca/~selinger/md5collision), it was discovered that anyone could easily generate multiple strings that would lead to identical hashes. This was a significant vulnerability that hackers used to violate secure computer programs and spoof security clearances and letters of recommendation.

Similarly, a pre-image attack is an attempt to match a *specific* hash. Instead of trying to find any match to any hash, the hacker tries to brute-force the discovery of a match of a particular password. Pre-image attacks work best against short passwords and hashes that can be performed quickly, so lengthening both passwords and the hashing time are essential to keep accounts safe.

### **Phishing and spoofing**

Finally, hashing can do nothing to protect users from phishing or spoofing attempts. These types of attacks don’t rely on any kind of technical attack. Instead, they are aimed at the user.

In a phishing attack, the hacker uses a fake website or email address to convince users that they’re interacting with a trustworthy source. This “spoofed” site or email will look exactly like the real version, with something small like a single letter changed. The hacker then convinces the user to “log in” to a fake site and instead just steals their account information. Hashing can’t prevent this because the attack happens entirely “offsite”.

## **The two halves of bcrypt**

The term “bcrypt” is a reference to two programs: crypt, the hashing function used by the [UNIX password system](https://docs.python.org/3/library/crypt.html), and Blowfish, a specific cipher that’s useful for password hashing. Here’s how each of these elements works in the context of bcrypt.

### **The root “crypt”**

The crypt algorithm is one of the original password protection solutions, reaching back to the earliest days of the digital revolution. In the 1970s, when crypt was first implemented, only about four passwords could be hashed per second. This essentially made brute force and pre-image attacks irrelevant.

However, by the late 1990s, a computer could use crypt to hash more than 200,000 passwords per second. In minutes, an attacker could successfully brute-force their way into any system using the same crypt algorithm.

Accordingly, the crypt function needed to be updated.

### **Blowfish: Where the “b” comes from**

What sets bcrypt apart from crypt is its use of the [Blowfish cipher](https://en.wikipedia.org/wiki/Blowfish_\(cipher\)#:~:text=bcrypt%20is%20a%20password%20hashing,threats%20from%20brute%20force%20attacks.). Blowfish is considered a “fast block cipher,” with one exception. The cipher uses a “key” to encrypt text. This key is not a password for the platform, but rather a filter that can be used to encrypt and decrypt files.

When Blowfish changes keys, it slows down dramatically because it needs to perform the pre-processing equivalent of encrypting four kilobytes worth of text. However, bcrypt uses Blowfish in an “off-label” way. Instead of saving keys to unencrypt any data, it hashes these keys to make breaking a hash more difficult. The keys can’t be used to unencrypt the hash because they’re actually part of the hash. So, instead of being used to “unlock” an encryption, these keys are used to “jam the lock,” thus making the hash harder to break.

Basically, bcrypt uses the Blowfish slowdown as a way to make other tasks longer — slower speeds are actually a good thing for password hashing. Niels Provos and David Mazières, the pair who created bcrypt, took advantage of the Blowfish slowdown by creating a key setup algorithm they called “eksblowfish.” This program, which stands for “expensive key schedule Blowfish,” is run to generate subkeys from the primary key, or the user’s password.

This is how the eksblowfish function performs something called “key stretching.” Many users will choose passwords that are short or common, meaning they’re easy to guess. The more times the hashing function is run, the longer it takes for the password to be checked against the original hash. Essentially, key stretching makes the calculation process take longer, so it “costs” more to crack the password.

The eksblowfish function also “salts” the password by adding random information to it. This extra information makes it stronger. Salts can be any length, but the longer they are, the more secure the password will be.

## **How bcrypt works**

So how does bcrypt actually work? That’s a good question. Like all hash programs, the fundamental method is simple: passwords are hashed, and the hashes are stored to compare against user inputs. It’s the hashing process where the difference is found.

The bcrypt hashing process heavily relies on the eksblowfish function. When the user inputs their password for the first time, the site uses “EksBlowfishSetup” to set two important parameters. First, it adds the “salt” to the password. A salt is a string of random characters used by the site to make passwords more complex.

Second, the EksBlowfishSetup will indicate the desired “cost” of the password. Remember, “eks” stands for “expensive key schedule.” The “expensive” part is the number of times the key schedule is run. Each iteration slows down the password process a little more.

Once the setup is complete, the eksblowfish function runs. The program then encrypts the value “ [OrpheanBeholderScryDoubt](https://news.ycombinator.com/item?id=24310173)” with the final state from the last run of the key schedule 64 times. The final string is a deeply secure hash that results from the combination of the cost, the salt, and the hashed input.

## **Why bcrypt is so secure**

Bcrypt is still a hash, so why is it more robust than other hashing functions? It’s because of the extra steps involved. The salt and key stretching function make bcrypt more secure against pre-image attacks. Since the salt is a random string, hackers can’t just run a rainbow table attack and hope for the best. The random element blocks these dictionary attacks from working.

Meanwhile, bcrypt is also resistant to brute force attacks — both now and in the future. The “cost” to hash a password is malleable and can be updated. So can the length of the salt. That means that as computers get faster, the cost can be set higher to keep the hashing process slow. This keeps hackers from simply guessing passwords by running the entire hash thousands or millions of times per second. Given that Moore’s Law still seems to be holding, this flexibility is critical.

## **How bcrypt compares to other hashing methodologies**

As well as bcrypt works, it’s not the only hash security function. Several other functions are regularly used to protect passwords against malicious users. Here’s how bcrypt compares to some of the most common alternatives.

### **MD5**

The widely used function [MD5](https://www.w3.org/TR/1998/REC-DSig-label-19980527) is a hashing function that was first developed in 1991. The function is considered cryptographically broken. An algorithm that’s regarded as broken is one that can be hacked without any preexisting information. In the case of MD5, it’s possible to generate collision hashes within minutes. Data security systems that rely on MD5 can be easily hacked by anyone with a basic understanding of the function.

On the other hand, bcrypt is not broken. As a result, it’s still able to keep passwords and information safe. Modern passwords should never be stored behind MD5.

### **SHA, SHA-256, and SHA-512**

There are three primary varieties of the SHA hash function. SHA, like MD5, is cryptographically broken. However, SHA-256 and SHA-512 are still considered secure. In particular, SHA-256 is one of the most common hashes for current website certificates.

Why is SHA-256 so popular? It’s because it’s a fast hash. It’s quick to run, so it’s able to quickly hash large amounts of data in a short timeframe. That’s precisely why it’s not ideal for passwords. The slower bcrypt is better for passwords because it’s more resistant to brute force attacks for the short amount of data in question.

### **PBKDF2**

PBKDF2 is considered secure. However, it’s another old solution to password hashing. While it does salt passwords, it’s also a lightweight program that can be run on a single core. When it was first developed, this made it secure but functional. Today, however, it’s a liability. It’s possible to parallelize PBKDF2 on multicore systems, dramatically cutting down the amount of time it takes to brute force passwords.

In contrast, bcrypt is not as easily parallelized. Consequently, it’s far more secure as an alternative.

### **Scrypt**

Scrypt is a follow-up program to bcrypt. It uses many of the same functions, but it’s significantly newer than bcrypt. In terms of security, this is not actually a good thing. Scrypt has received half as much scrutiny and testing as bcrypt has just because of the time it’s been in use. While there have not been significant vulnerabilities discovered yet, it simply isn’t as well-tested. Though scrypt claims to be more secure, organizations looking for a better-tested option will still see more reliable results from bcrypt.

### **Argon2**

[Argon2](https://www.argon2.com) is a new, award-winning password hashing function that’s become well-known in the cryptography community. However, for online and web-based passwords it has some weaknesses. If users are looking for short hashing times, Argon2 and its derivations are actually weaker than bcrypt. The way Argon2 functions relies on longer runtimes for security, while bcrypt just relies on iterations. Argon2 is also newer, so it hasn’t been tested as thoroughly. Essentially, bcrypt is considered more secure for any application designed to allow sign-ins in less than a second.

## **Final Thoughts**

The bcrypt function may be older than some, but it’s stood the test of time. Though there may be modern algorithms that might have some theoretical advantages, they have not been as extensively tested. Until they have, or until bcrypt shows meaningful vulnerabilities for a password hashing or security use-case, it’s likely to remain the industry standard.

[Clerk](/) uses bcrypt to keep passwords secure, and can help it implement highly-secure, well-tested user authentication that will keep your user information safe.

---

# History and Rise of "Passwordless"
URL: https://clerk.com/blog/passwordless-history-popularity.md
Date: 2021-09-29
Category: Insights
Description: Learn the history of passwordless, and how it became popularized. From OTPs to MFA to mobile.

## **A Brief History of Passwordless**

Passwords have been our main digital authentication method since 1961, though its [vulnerability to hacking](https://itd.sog.unc.edu/knowledge-base/article/hacking-hacked-password-security-digital-age) was demonstrated within one year.

Encrypted password storage and public-key cryptography were developed in the late 60s to early 70s.

But the 1980s brought the first version of “passwordless” authentication. This came in the form of dynamic, one-time passwords (OTP) held on physical fobs.

OTPs eventually developed into two protocols: time-based OTPs (TOTP) and cryptographed hash-based message authentication codes or HMAC OTPs (HOTP). Dynamic OTPs are still widely used as an authentication protocol.

The late 1990s brought single sign-on (SSO) into use. SSO helped organizations manage user authentication across an entire network of applications. However, fobs and other hardware tokens remained in use and popular throughout the 1990s and 2000s.

Smart cards are one hardware token that emerged in the early 2000s. These physical electronic authorization cards are sometimes used as passwordless [security tokens](https://en.wikipedia.org/wiki/Smart_card#Computer_security).

The 2000s also saw the combination of these various passwordless and password-based authentication methodologies with the rise of *multifactor* authentication. AT\&T actually holds the earliest recognized patent dating to 1998, but multi-factor auth (MFA) and single sign-on (SS0) really took off when organizations like Google began building them into their applications as a form of password-independent authentication.

The financial sector adjusted quickly. In 2005, the Federal Financial Institutions Examination Council (FFIEC) set out new user authentication guidelines. These included multi-factor authentication, biometrics, OTPs, and token-based authentication.

## **How Passwordless was popularized**

As MFA and thus passwordless authentication strategies became more popular, passwords and authentication itself became a popular topic again.

The first sign of media interest was at a [2004 IT security conference](https://news.microsoft.com/2004/02/24/gates-details-security-related-technology-investments-and-innovationsat-rsa-conference-2004), where Bill Gates publicly advocated for making passwords obsolete. Gates went over several of the security threats inherent to knowledge-based passwords. He then advocated for newer authentication technologies, including a tamper-resistant biometric ID card.

In late 2011, IBM [predicted](https://www.networkworld.com/article/2184221/ibm-predicts-five-big-technologies-of-the-future.html) that “multi-factor biometrics” would become the dominant authentication protocol, creating a completely passwordless world. Their influential thought leadership spawned many other predictions and thought pieces.

Google pushed things further in 2013, when [Eric Grosse, VP of security engineering, stated](https://www.computer.org/csdl/magazine/sp/2013/01/msp2013010015/13rRUx0xPgv) that "passwords and simple bearer tokens, such as cookies, are no longer sufficient to keep users safe." The company then made multi-factor authentication protocols standard within the organization, and that same year, Google’s information security manager, Heather Adkins, put it bluntly, “Passwords are done at Google.”

Then in 2014, after Russian hackers [accessed the login credentials](https://www.computerworld.com/article/2490980/russian-credential-theft-shows-why-the-password-is-dead.html) for over 1.2 billion internet users, Avivah Litan, VP Analyst at Gartner, reiterated the need to go passwordless. In her words, “Passwords were dead a few years ago. Now they are more than dead.”

Finally, the rise of mobile has boosted the popularity of passwordless authentication. In 2013, Apple introduced Touch ID (and Face ID has since followed) making passwordless biometric authentication ubiquitous today. Additionally, passwordless strategies (i.e. sending an SMS-based [magic link](/blog/magic-links)) allowed mobile-first businesses, like Uber and Lyft, to authenticate users and perform account verification in a single easy step.

## **Is “Passwordless” here to stay?**

There is no doubt that authentication technology and methodology will continue to evolve. The number of viable authentication methods will continue to grow, and inherently, most of these will be a passwordless one. Since two-factor and multi-factor authentication are widely popular (and in many use-cases a requirement), passwordless is definitely here to stay.

However, this doesn’t mean that password-based methods will be completely replaced or that passwordless is right for everyone. To learn more about specific passwordless technologies and if they’re the right choice for you, keep reading our series on passwordless authentication.