# Clerk Blog — Insights — Page 2

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

---

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

---

# Session management: What it is and why your security depends on it
URL: https://clerk.com/blog/what-is-session-management.md
Date: 2021-09-21
Category: Insights
Description: Learn about session management, its components, and security concerns.  

Constantly having to log back in to your online accounts is a frequent annoyance — but this irritating problem stems from an inefficient solution to a genuine security concern.

Web applications need to make sure that your accounts are safe from hackers, and some handle that by requiring frequent re-authentication. Still, that’s not the best solution. Proper session management can help apps like yours keep users safe *without* needing to constantly log back in.

Below, we’ll cover the fundamentals of session management, what’s required to implement it, and how it can help you keep your users safe without creating a frustrating user experience.

## What is session management?

[Session management](https://www.packetlabs.net/session-management) is the process of facilitating private interactions between users and web applications. It specifically refers to managing different “sessions,” or periods when the user is logged in and active in the application. The session management process lets users access their unique and potentially sensitive information securely without letting others get into their account, without forcing users to constantly re-authenticate.

Session management can take two forms: short-lived and long-lived. Short-lived sessions last only as long as the user remains in the application. Every time they leave the app, they need to re-authenticate to get back in.

Long-lived sessions keep the user logged in to the app even if they leave. These sessions store session IDs on the user’s device, allowing them to reopen the app and start using it without needing to re-authenticate.

Long-lived sessions typically offer the best user experience, since they let people get into their accounts with no hassle. But this approach also has drawbacks. Anyone who accesses the device can also access that account as long as the session is still active, which is a security risk. For apps that contain sensitive information, short-lived sessions may make the user experience slightly more complicated, but will be more secure.

## The elements of session management implementation

Proper session management implementation involves three functions: creating session IDs, storing session cookies or tokens, and enforcing session expiry dates.

Here’s what that means:

### Session IDs

When the user first logs into the website or app, the server creates a unique session ID associated with the authenticated user. However, with each new request, the server still needs a way of identifying if the request came from that authenticated user without needing re-authentication. Which is where cookies or [JWT](https://en.wikipedia.org/wiki/JSON_Web_Token) tokens come in.

### Session cookies vs. tokens

When the server creates a unique session ID, it also creates a cookie that is stored in the user’s browser. The information contained in that cookie is sent along with each new request so the server understands it comes from the same authenticated user.

Session cookies are most commonly used with websites or web-based platforms. When it comes to modern web applications, a JSON Web Token, or JWT, is used instead.

When the user logs on with the right credentials, a JWT is created instead of a session ID and sends it to the user. The JWT is stored in local storage and the header of the token is sent with every new request.

This means that the user’s state is not stored on the server, but inside the token, making this option more scalable and more useful for mobile device authentication.

### Session expiry

Sessions are temporary states and expire under certain circumstances, such as the mobile app being closed, a set period of inactivity, or a maximum session duration that cannot be exceeded. Long-lived sessions may expire when the user hasn’t interacted with the app in a certain number of days or weeks. The cookie or token storing the session ID should automatically delete itself at the end of those periods.

## Security concerns addressed by well implemented session management

The purpose of session management is to help keep user data secure. Without appropriate session management, you can run into several security problems, putting your users at risk. Common vulnerabilities caused by a lack of or poorly implemented session management include:

### Session hijacking

The cookies that you use to store session IDs need to be truly secure. Insecure session cookies are easy for hackers to predict or to use for brute-force attacks. If a hacker can spoof your users’ session IDs, they can impersonate users and take over their accounts. This is known as session hijacking, and it can lead to the loss of sensitive information connected to the account.

### Session fixation

If a specific session token can be used across platforms and without proper expiry protocols, it can be “fixated” by hackers. Essentially, the hacker tricks a user into logging in with a specific session ID, often by adding to the session ID in the URL argument, and then uses those credentials to log in to the user’s account.

### Session resources

Session management systems should beare resource-light, so that attacks, such as denial of service (DDoS) that flood the system with new session requests, don’t consume huge amounts of resources.

### Anomaly detection

Every application runs the risk of hacking attempts. If your session management tool doesn’t have a way to detect abnormal patterns like brute force session ID guessing or DDoS attacks, you’re more likely to fall victim to these attacks.

### Session expiry unset or too long

Session expiration has two potential problems. If you don’t set the timeout period, many programs may leave the cookie or token on the device forever, leaving the account vulnerable to anyone else with the device. Also, a set timeout period that’s too long has the same issue.

## Stay secure with session management

Proper session management addresses all these concerns. It keeps your users and accounts safe by providing secure cookies or tokens, setting appropriate protocols and timeouts, and implementing anomaly detection.

Session management is a fundamental part of running a secure, trustworthy web application. By keeping a handle on your users’ sessions, you can help them avoid the hassle of constant re-authentication without putting them at risk.

You can address all your session management needs by implementing a [user management](/) service, or you can write your own. Either way, your users will thank you for protecting them without making their lives more difficult.

---

# Don’t underestimate the value of a secure, seamless ‘forgot password’ flow
URL: https://clerk.com/blog/forgot-password-sspr.md
Date: 2021-09-16
Category: Insights
Description: Learn about “forgot password” flows, how they work, and the best practices to keep in mind.


Just about every software application today relies on individual user accounts to provide people with a personalized and private experience. However, as [“software eats the world,”](https://a16z.com/2011/08/20/why-software-is-eating-the-world) the average user is managing an increasing number of accounts. Practically every online store, social media platform, SaaS product, newsletter, game, and group requires users to create an online account with a username and password. The average American adult has a total of [130 online accounts](https://www.prweb.com/releases/dashlane_study_us_internet_users_drowning_in_online_accounts_with_further_tidal_wave_approaching/prweb12860738.htm) — and they all need to be kept secure, which exacerbates an already all-too-common problem: lost and forgotten passwords.

That’s why most apps offer password reset flows. This essential workflow allows users to reclaim their accounts while maintaining their security and privacy. Keep reading to learn about “forgot password” flows, how they work, and the best practices to keep in mind.

**‌**

## **What is a ‘forgot password’ flow?**

If you’ve ever had to reset a password, you’ve gone through a “forgot password” flow. Users go through this self-service process to reset their passwords and reclaim their accounts. Any website, app, or other account that relies on passwords for security should have some kind of reset flow.

**‌**Why? Because users are prone to forgetting their passwords. It’s also common for people to forget their accounts entirely or change devices and lose their saved passwords. Without some way for users to quickly and easily reset passwords and reclaim accounts, you may lose users, have to support multiple accounts for the same user, and/or deal with an overwhelming number of “forgot password” support requests.

**‌**

## **How ‘forgot password’ flows work**

Password resets can be manual or automatic. Manual resets rely on the user reaching out to support by email or phone. The support team member asks them some kind of security or verification questions and resets their password accordingly. However, manual flows mean that a significant percentage of your support tickets will be password resets, taking up your staff’s valuable time. Additionally, manual verification is often less secure than an automated process, and can be especially frustrating for a user that needs access quickly.

**‌**The alternative is to implement a [self-service password reset](https://www.hcinnovationgroup.com/home/article/13005329/password-resetting-goes-the-selfservice-route) (SSPR) process. These automated workflows allow users to reset their passwords or reclaim their accounts without human intervention. They’re used by most websites, apps, and other password-protected systems to streamline the security process. Your support staff won’t need to spend time answering password reset claims and can focus on more important work.

Each type of self-service flow works a little differently. For example:

- **Temporary passwords:** This process will send the user a temporary password that they can use to access the system. The user then resets their password themselves once they’re logged in.
- ‌**Email verification:** The system emails the user a link at their primary email address, and the link takes them to a dedicated password reset page.
- ‌**SMS verification:** The system sends the user a text to confirm they want to reset their password, with instructions to follow the reset link.
- ‌**Passwordless logins:** Passwordless flows send a one-time link to the user’s email or phone, allowing them to log in without resetting their password at all. This can be great for a user that just wants to log in from a different device one time, or is pressed for time and wants to reset their password later on
- ‌**Two-factor authentication (2FA) reset:** Two methods are used instead of one to confirm the reset. The user confirms their identity one way and then resets their password with another method. The system may have them check their email or phone for the reset link, and then on the reset page, it may ask for a code that was sent to their phone or a sign-in authentication app.

**‌**

## **Why implementing SSPR workflows can be challenging**

While password reset systems are essential, they can be a complex feature to implement on your own. Rolling your own password reset process means dealing with:

- **The constant evolution of best practices.** [Best practices](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md) regarding SSPR workflows are constantly evolving - from manual reset to security questions to email reset to SMS workflows to passwordless logins. You should keep up with these changes to make sure your password reset process stays secure and up-to-date.
- ‌**Security maintenance.** Password resets need to be a secure workflow end-to-end, or your users’ accounts are at risk of being hacked. If you write your own, designing a secure process is your responsibility.
- ‌**Design and integration.** Your reset process might be technically sound, but it should also be frictionless and well-designed, as an easy sign in experience is critical to retention.
- **Complexity**. Adding more authentication features and options can provide an excellent user experience when everything works right, but it also creates the potential for more “edge cases” where problems occur.

**‌**‌**‌**

## **Get started with password resets today**

If your team has more pressing features to focus on than creating a password recovery flow, [Clerk](/) can eliminate the guesswork (and real work) of user management and authentication. Clerk makes it easy to add complete user management to your app in minutes today, while allowing you to easily make changes and add new features in the future.**‌**

---

# Designing fast sign in forms— diving into the data
URL: https://clerk.com/blog/designing-fast-sign-in-forms.md
Date: 2021-06-17
Category: Insights
Description: Key insights on building fast sign in forms with Social Sign In, password-based, and passwordless authentication.

The modern web is obsessed with speed. Just this week, Vercel [launched Next.js 11](https://nextjs.org/blog/next-11) with a special focus on [Core Web Vitals](https://web.dev/vitals), a new set of Google metrics that are measured in tens of milliseconds to determine page speed. Google has noticed that faster websites mean better user experiences, and has incorporated these metrics into their search ranking algorithms.

At Clerk, we're focused on a speed challenge that's equally important but often neglected: **how quickly can users sign in?**

In working to optimize our prebuilt Sign In UI, we've had a few surprising insights we thought are worth sharing.

## Social Sign In deserves the top spot

After much qualitative debate - Clerk originally launched with Google and Facebook sign in buttons *below* the option to sign in by email.

After collecting a few months of data, we realized we should make an adjustment. There was a near-perfect 50/50 split between users who preferred Social Sign In vs email and password. But, Social Sign In was faster: \~5 seconds on average compared to \~8 seconds for email and password. So we made the switch:

![Designing Fast Sign In Forms tutorial illustration](./714c2cb7ab631cfa11a4ea560116103434d62de5-2400x1600.png)

In the months since making this change, Social Sign In usage has started to outpace email and password, with the last month seeing a 52/48 split.

As expected, since more users are now using a faster authentication strategy, the change has also resulted in a faster overall sign in speed.

## Passwordless should remain a fallback

The passwordless concept has existed in authentication systems for decades. If a user forgets their password, a code or link is emailed to them for authentication without a password.

Recently, there has been a lot of buzz about promoting passwordless flows to the primary authentication mechanism. While Clerk allows developers to configure their Sign In this way, we recommend against it, and suggest leaving it as a fallback.

On average, we see passwordless flows take \~35 seconds to complete. Despite using Sendgrid to deliver our emails quickly and with high inbox rates, the process of checking email is simply *slow* in comparison to Social Sign In or email and password.

## The "edge cases" of Social Sign In are surprisingly common

While building Clerk, we cataloged our frustrating sign in experiences across the web and made sure we had a resolution. The source of much frustration was Social Sign In - even amongst the web's biggest properties, we came across sign in flows that were blocking users from using Social Sign In if they hadn't originally signed up that way:

![Designing Fast Sign In Forms tutorial illustration](./9730f6175509949c5ee0d18fb99e83cc7b61b424-2000x1333.png)

While it's obvious that roadblocks like these slow the sign in process, handling them elegantly takes a lot of development time. Many developers are comfortable pushing off a proper solution because these scenarios feel like edge cases.

In practice, we've learned that these "edge cases" are surprisingly common. In fact, 15.9% of users who have used Social Sign In have also used another method. Of those:

- 2 in 3 originally signed up with a password then later chose Social Sign In
- 1 in 3 originally signed up with Social Sign In, then later tried signed in without (they were sent a code to their email)

At Clerk, we've invested heavily in handling these scenarios as elegantly and quickly as possible. Regardless of a user's choice of sign in strategy, they will always be linked to the same underlying account.

## Clerk's prebuilt Sign In UI

Clerk enables developers to add beautiful, high-conversion Sign In form to their application in minutes. Our prebuilt UI can easily be themed to match any company's brand and style guidelines.

We're constantly analyzing the data in search of better user experiences, as well as evaluating new technologies for addition to our product. If you have questions or ideas for improvement, reach out to us on X [@clerk,](https://x.com/clerk) or [through support](https://clerk.com/contact/support).

---

# Build or Buy? A Look at User Management with Next.js: Part 1
URL: https://clerk.com/blog/build-or-buy-user-management-with-nextjs-1.md
Date: 2021-06-15
Category: Insights
Description: In this article, you'll learn the pros and cons of developing or buying a user management system so you’re ready to make the right choice for your project.

User management is one of the most critical components of any consumer-facing application. Put simply, a user management system is responsible for creating, managing, and removing users. It provides users a way to authenticate themselves so they can use the application, and it offers admins a way to manage the user store. Any application designed to serve users must have a user management system, either developed in-house or bought from a third-party vendor. However, with the advent of modern software development and the rise of various security threats, a simple username-and-password sign-up and sign-in often isn’t enough. The dilemma faced when building an application is if you should build or buy a user management solution.

## Features of a User Management System

A complete user management system comprises a multitude of different features. Here are some of the most important.

### Authentication

Authentication is an essential part of a user management system, as it acts as the entry point for your application. Although a simple username-password or email-password authentication is possible and works for small applications, there are alternative authentication mechanisms that can offer extra convenience and security. You can eliminate the need for passwords by using [email magic links](/blog/magic-links). Although magic links are 4.1x slower than using passwords, they can provide a seamless sign-in and sign-up experience, as well as prevent bot attacks and account takeover risks related to having a password that can be compromised. [Single sign-on (SSO)](/features/social-sso) is another important feature—one that’s 1.3x faster than using passwords. With SSO, users can use their existing account with a third-party service (e. g. Google, Facebook. etc.) to sign in to your application. In addition to being fast, SSO is the preferred method for authentication for 53% of users, resulting in higher conversion rates.

To offer the best possible experience for your users with social SSO, your application must support a wide range of social SSO providers: Google, Facebook, Twitter, GitHub, GitLab, and Discord are the most common. The more social SSO providers you support, the more likely it is that users can use their preferred provider to sign in to your application. Another recommended feature is automatic account linking—if a user signs in with SSO after creating their account with another form of sign in, a new account shouldn’t be created; rather, the SSO should be linked to the original account.

Another consideration is [multi-factor authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication). It's a way to add extra security to your application by requiring users to enter their password and a second factor such as a security code, and is strongly [recommended](https://www.getcybersafe.gc.ca/en/blogs/why-multi-factor-authentication-essential-part-cyber-security), especially for applications where users might store sensitive information.

### Session Management

When a user signs into an application, a session is created, which saves the user from needing to log in with every request. This session must be maintained for the duration of the user's active period, and be destroyed when they sign out. A robust session management system must provide security features like [XSS leak protection](https://clerk.com/docs/security/xss-leak-protection), [CSRF protection](https://clerk.com/docs/security/csrf-protection), and [session leak protection](/docs/security/fixation-protection). In some instances, a multi-session feature can also be useful, allowing users to have multiple accounts and switch between them seamlessly, without having to log out and log in again.

### User Profile Management

A centralized profile/settings page where users can edit their personal information, such as name, email, and profile picture, and security details, such as password, multi-factor authentication preferences, and connected accounts and devices, is another important component of a user management system.

### User Interface

The user-facing side of the user management system is equally important. A poorly designed user interface or clunky user experience can turn potential users away. Whether you buy or build a user management solution, make sure that interfaces like the sign-in page, sign-up page, profile page, etc., are well designed and match the rest of the application.

### Integrations with Other Components

Your user management system should be easy to integrate with the various parts of the application, and flexible enough to allow any future integrations. For example, if you're building a web app, it's quick and easy to build a user management system that is coupled tightly to the web app. But if you build a companion mobile app in the future, you’ll need to either separate the user management system into its own service that the mobile app can communicate with through APIs, or build a separate system for the mobile app—both time-consuming and costly solutions. So it's vital to start with a user management system flexible enough to handle both what you need right now, and what you might need further down the line.

## Pros and Cons of Building a User Management System

In-house development of a user management system offers some advantages. First of all, you get a highly customized system for your application. The design can be tweaked to match your requirements exactly. You also have complete control over how it works and integrates with other components. You can make changes to it when needed, and roll updates whenever and however you want.

Building a user management system might be tempting because of the control that it offers. But before you start building, take a look at the disadvantages.

As you can see from the number of features listed above, a complete, future-proof user management system is incredibly challenging to build, and you'll need a diverse team to tackle it. Developers with expertise in different domains—including database security, cryptography, cybersecurity, system engineering, and of course, developers familiar with the ever-changing landscape of user management—are needed for in-house development.

To build a user management system from scratch also requires you to invest a significant amount of time, money, and engineering power. Devoting resources to the development and ongoing maintenance of a user management system means fewer resources for critical business operations and the development of the core application features. Unless you have manpower to burn, you're probably better off having your developers and resources focused on developing the core application.

A user management system must also be secure enough that users are comfortable entrusting their data to your application. While hashing and salting passwords with an algorithm like [Bcrypt](https://en.wikipedia.org/wiki/Bcrypt) is standard, the security measures shouldn't stop there. Standards like [NIST 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) should be followed to ensure the highest possible security standard. Proper protection against brute force attacks, dictionary attacks, and [credential stuffing attacks](https://owasp.org/www-community/attacks/Credential_stuffing), as well as using a service like [HaveIBeenPwned](https://haveibeenpwned.com) to prevent the use of previously leaked passwords, is a must. You’ll also need to rate limit the endpoints to protect the system from [DDoS attacks](https://us.norton.com/internetsecurity-emerging-threats-what-is-a-ddos-attack-30sectech-by-norton.html). Automated logging and monitoring of all activities must be implemented, and alerts for suspicious activities should be set up to prevent data breaches.

Since the user management system provides the entry point to your application, it needs to be highly available, and must scale in response to increasing load—it can’t crash because too many users are attempting to log in at once.

Even after successfully building a user management system, the hassle doesn't end there. You need to constantly monitor, audit, and improve the code to ensure security. Failure or delay runs the risk of the application being [compromised](https://www.contrastsecurity.com/security-influencers/a-week-of-web-application-hacks-and-vulnerabilities). You'll need an experienced DevOps team to deploy and maintain the user management system to ensure it stays up and running.

## Pros and Cons of Buying a User Management System

Buying a user management system alleviates many of the challenges of user management systems. You don’t have to worry about the scalability or availability of the system, since the service provider will handle them. The security concerns are also lifted from your shoulders, and best practices are already implemented. Reputable vendors, such as [Clerk](/), supports almost any available [social SSO providers](/features/social-sso). They also offer libraries for different programming languages and frameworks such as [Next.js](https://nextjs.org), as well as prebuilt [UI components](https://clerk.com/docs/components/overview). This means you can quickly integrate the user management system with your codebase. You'll also get full technical support from your service provider if you run into any issues.

Though buying a user management solution makes user management easier, there can be some downsides. The biggest concern lies in the fact that you don’t have complete control over the service. You can evaluate different service providers and choose the one that works best for you, but it may be hard to find one who meets all of your requirements. You can always provide feedback or request new features, but implementation is ultimately up to the service provider.

The service provider is also in control of your data, and it can be difficult to verify their level of security before entrusting valuable user data to them. To ensure your data is in good hands, you’ll need to evaluate the policies and practices of the service providers you’re considering. For example, [Clerk](/) has a [secure-by-default philosophy](https://clerk.com/docs/security/overview) and a [responsible vulnerability disclosure policy](https://clerk.com/docs/security/vulnerability-disclosure-policy), which ensures that all the data is properly protected.

The possibility of vendor lock in is another concern. Once your application is tied to a particular user management system, it becomes difficult to switch to a new vendor if the need arises. You'll have to manage the change of vendor without breaking your application.

## Build or Buy?

Now the advantages and disadvantages of each approach are clear, let's answer the title of the article. Should you build or buy? The answer is *it depends*.

You might opt for building a user management system if:

- You only require basic features, like username-password authentication. You can build this yourself using libraries like [next-session](https://www.npmjs.com/package/next-session). For a very simple project, you might be able to use one or two social providers and get away without a username/password database.
- You need a highly customized solution tailored to your needs, and can’t find a service provider that can meet the requirements.
- You have an expert team of highly experienced developers, and you have enough resources to continue developing core business features.
- You're on an extremely tight budget. Although [authentication providers like Clerk](/nextjs-authentication) are free for 500 MAU and only cost $10/month after that, sometimes budget restrictions might force you to make a compromise between buying a user management system and buying some other essential service.

For almost all other cases, it's preferable to buy a user management system. It's the sensible choice when:

- You want to get your product to the market as quickly as possible.
- You want a robust, future-proof user management system.
- You want to save on costs, and don't want to waste resources on reinventing the wheel.
- You don’t have a team of developers who are well versed in the technologies required to create and maintain a user management system.
- You want to focus the organization's resources on the core business operations.
- You have a small userbase that can fall under the free tier of your provider.

## Conclusion

To build or to buy—that's the age-old question of the software development world. Since user management is a crucial part of applications, it makes sense to have a comprehensive, robust system. In this article, you explored the various features of user management systems and looked at the pros and cons of building and buying user management systems.

In the [next part](#link-to-next-part) of this series, you'll follow a hands-on tutorial to build a user management system from scratch with [Next.js](https://nextjs.org), as well as see how to use [Clerk](/) to achieve the same result.