# Clerk Blog — Insights
# What is multi-tenancy and why it matters for B2B SaaS
URL: https://clerk.com/blog/what-is-multi-tenancy-and-why-it-matters-for-B2B-SaaS.md
Date: 2025-06-17
Category: Insights
Description: Learn what multi-tenancy is, why it matters for B2B SaaS apps, and how it shapes your architecture decisions.
Let's assume you’re building a SaaS product for engineering teams to manage their cloud repositories and deployment workflows. We’ll call it **“HubGit.”**
You already have some early customers on your waitlist, each with its own team of developers, repositories, and even CI/CD pipelines. Naturally, you want every developer at these companies to authenticate securely, see only their organization’s code and workflows, and collaborate exclusively with their colleagues. But you don’t want to build and maintain a separate app or backend or database for every organization.
That's where multi-tenancy comes in.
Multi-tenancy is the architecture behind most B2B SaaS products today and it's what makes them scalable and cost-effective as their customer base grows. When Slack serves millions of workspaces, or when Shopify powers hundreds of thousands of stores, they're likely not running separate applications for each customer. They're running one powerful multi-tenant system that delivers isolated experiences for every single tenant.
> Ready to build your B2B SaaS with multi-tenant authentication? [Learn more about our B2B SaaS solution](/b2b-saas).
In this article, we’ll explore what multi-tenancy is, why it matters for B2B SaaS, and how to design for it. Specifically across our multi-tenant series, we’ll cover:
- Common architecture patterns, database strategies, and authentication factors/challenges.
- Practical steps for implementing multi-tenant authentication flows that work in production.
- Examples of real-world applications using multi-tenancy
## What is multi-tenancy?
At its core, [multi-tenancy](https://clerk.com/glossary/multi-tenancy) is an architectural design pattern that allows a single instance of an application to serve multiple customers (or "tenants") while keeping their data, configurations, and workflows isolated from one another. Each tenant acts as a separate entity, with unique users, settings, and authentication factors.
Take Shopify, for example. When a store owner signs up for Shopify, they're not just getting a traditional user account. They're getting an entire isolated tenant/organization account where their products, orders, customer data, payment settings, themes, and even custom apps are completely separate from every other Shopify store. This demands a full multi-tenant architecture, with tenant-isolated authentication flows where users might belong to multiple organizations, custom security policies per tenant, isolated databases or schemas, and even different compliance requirements for each business.
However, it’s important to mention that not every SaaS app needs multi-tenancy. If you're building a SaaS app that caters directly to individuals and would never cater to groups of individuals, you don't have to worry about multi-tenancy. You literally don't need it. But if you're building a B2C SaaS for shared use cases, or building a B2B SaaS that you plan to sell all the way up to enterprise at some point, the foundation of your architecture has to be multi-tenant.
## Why multi-tenancy for B2B SaaS?
Multi-tenancy is a foundational decision that shapes how SaaS products serve B2B customers with wildly different requirements as they scale.
Think of it this way: businesses are inherently complex. They have multiple departments with employees who need different levels of permissions, and these teams often grow, and members change over time. Multi-tenancy helps you model these real-world organizational structures and requirements in a clean, programmatic way, from inviting teammates and assigning roles, to isolating usage/data at the org level. It’s designed to handle the complexities of how businesses actually work.
But here's where it gets really interesting. When you have multiple tenants who probably have different business requirements relying on a multi-tenant infrastructure, they're all pushing it to grow in multiple directions. The eCommerce company needs better payment processing. The healthcare startup needs stricter compliance features. The manufacturing company needs bulk data imports. While each tenant may be pushing for improvements in the context of their isolated portion, everyone ends up benefiting from these "isolated improvements" because they all share the same infrastructure.
There are even more reasons why multi-tenancy is the bread and butter of [SaaS architecture](https://clerk.com/docs/guides/multi-tenant-architecture). Let’s break them down:
- **Faster feature rollouts:** With a single codebase serving all tenants, every feature you launch is immediately available across your customer base. You write code once, and every tenant gets it immediately. Compare this to single-tenant deployments where you're maintaining separate codebases and coordinating dozens of different rollouts. That's a nightmare!
- **Cost efficiency:** Running one shared application that serves multiple tenants is fundamentally cheaper than managing separate applications and deployments for each tenant. You have less infrastructure to monitor, fewer environments to maintain, and simpler disaster recovery SLAs.
- **True scalability**: With multi-tenancy, adding a new customer doesn't mean provisioning new isolated servers or cloud environments. It's often just creating a new organization record in your database. As you grow, your architecture doesn't fundamentally change. Your core multi-tenant design will stay the same whether you're serving 100 tenants or 100,000.
## What are the risks of not going multi-tenant?
Many developers think they can start building their B2B SaaS with a B2C architecture and "add multi-tenancy later," but this approach creates fundamental data model problems that are exponentially harder to fix as you scale. Let's explore some of the technical debt and engineering challenges you'll face if you try to avoid multi-tenancy from early on:
- **Database migrations:** Every schema change would require coordinating migrations across dozens or hundreds of separate databases since tenants are practically isolated. What should typically be a simple column addition to the DB becomes a complex activity requiring unique execution for each tenant, because one failed migration can leave you with inconsistent schemas across your DB with no clean way to recover.
- **Monitoring and debugging complexity:** When issues arise, you can't just check one set of logs or metrics. You're hunting across multiple databases, separate application instances, and isolated environments to understand what went wrong. Root cause analysis becomes a an unending job across disconnected systems, making critical bug fixes take days instead of hours.
- **Resource scaling becomes impossible:** Without shared infrastructure, scaling requires provisioning new servers, databases, and environments for each tenant individually. Auto-scaling becomes impossible when you're managing hundreds of separate deployments. Performance optimization means profiling and tuning dozens of different environments instead of optimizing one shared system.
- **Data backup and disaster recovery:** Each tenant needs separate backup strategies, disaster recovery procedures, and data retention policies. In the event of any disaster, you're not restoring one system, you're coordinating recovery across multiple isolated environments with different states and dependencies.
## Example features of multi-tenant SaaS apps
Let’s look at some practical examples of how multi-tenancy could show up in SaaS applications. These examples highlight how multi-tenancy supports the dynamic needs of B2B customers while still letting your SaaS serve every organization from one shared infrastructure:
- **Collaborative workspaces:** If you’re building a B2B SaaS, your app should natively support collaborative workspaces (sometimes called organizations, teams, or tenants) where users can be invited or request to join based on their roles and permissions. Think of tools like [Slack](https://slack.com/help/articles/115004151203-Workspaces-overview), where each workspace operates as an isolated tenant with its own users, data, and integrations, or [Notion](https://www.notion.com/help/category/sharing-and-collaboration), which allows granular sharing and collaboration settings across teams. Your app must securely manage user invitations, role assignments, organization settings, and seamless tenant switching—all while maintaining strict data isolation.
- **Organizational/Admin dashboards:** Every B2B organization typically has an admin or owner who needs to manage everything from user accounts and memberships to billing, integrations, and usage analytics. Your B2B SaaS must provide a robust account management portal—not just for admins, but also for end users to manage their membership status, security settings, billing details, and MFA preferences. A great example of this is [Stripe’s account management portal](https://docs.stripe.com/dashboard/basics), which sets a high bar for clarity and functionality. Admins should be able to send invites, assign roles, review join requests, and remove users with ease.
- **Roles and permissions:** Supporting bespoke multi-tenant authentication and authorization goes well beyond basic RBAC. Each organization often has its own roles, permissions, and workflows that don’t fit standard, pre-defined templates. While your B2B SaaS should offer default roles like admin and member, it also needs to support custom roles that developers can define to meet the specific needs of each tenant. [Clerk’s roles and permissions system](https://clerk.com/docs/organizations/roles-permissions) is a strong example of how to enable fine-grained access control at the organization level.
- **Org-specific auth flows and settings:** From custom authentication methods to unique UI and branding requirements, organizations often need configuration settings that are isolated from other tenants. Your B2B SaaS must support these custom policies at the org level—whether it’s enforcing SSO, requiring email verification, or restricting sign-ups to certain domains. A good starting point for building this kind of tenant-aware auth experience is Vercel’s [Next.js + Clerk authentication starter](https://vercel.com/templates/next.js/clerk-authentication-starter), which provides a ready-to-use foundation for customizing auth per organization.
## Up Next: Designing multi-tenant SaaS architectures
Now that we've established why multi-tenancy matters for B2B SaaS, our next post will explore how to design and build these systems. You'll learn how to architect a multi-tenant SaaS platform that scales from your first 10 users to your next 10,000 and beyond.
---
# Seamless Integration: How Clerk Streamlined OpusFlow's User Authentication
URL: https://clerk.com/blog/opusflow.md
Date: 2023-05-15
Category: Insights
Description: Learn how Clerk's user-friendly authentication system streamlined OpusFlow's SaaS integration, enhancing productivity and performance.
\_"We were blown away by the user-friendly authentication system that Clerk.com provides, allowing our SaaS to easily integrate with multiple teams of different skill levels. Not only did it offer MFA capabilities and organizations for a more efficient team, but its seamless integration into our tech stack resulted in an unbelievably productive experience! As CTO of OpusFlow, I'm extremely pleased with the 'just work' concept delivered via Clerk."
– **Joey Teunissen, CTO OpusFlow**\_
## About OpusFlow
[OpusFlow](https://opusflow.io) is the perfect ERP system for businesses dealing with installations, like solar panel systems, heat pumps and charging stations. OpusFlow's mission is to streamline efficiency within installation companies through automation of time-consuming processes. With this one-stop solution at your fingertips, you can rest assured that tedious manual tasks are no longer taking up precious hours in your day!
## **Tech Stack**
We have crafted an innovative tech stack to ensure the smooth operation of our platform. On the frontend, Next.js is utilized while PostgreSQL and Node.js run on a serverless system with Typescript and GraphQL compatibility. Hosting solutions are provided by Netlify in combination with AWS services for maximum performance and scalability.
Frontend: Next.js\
Backend: Node.js, Typescript, GraphQL, PostgreSQL, Serverless\
Hosting: Netlify, AWS
## **Before Clerk**
After many attempts at various authentication methods for our projects – from custom-made to Auth0 and others – OpusFlow soon realized the complexity that is often associated with these approaches. To simplify this process, we conducted extensive research until Clerk.com, a developer-friendly authentication platform, was discovered. After conducting a Proof of Concept test to ascertain its performance and reliability, Clerk became our obvious choice for internal projects. We quickly made the switch! Following the successful use of these projects, we decided to take it one step further and implemented Clerk into our largest enterprise SaaS ERP system yet.
## **After Clerk**
After using Clerk for an extended period, with numerous groups that consisted of anywhere from four to ten developers at a time, we are thrilled about the possibilities in store. It is already sufficient enough for our needs as it stands now and its support system provided by Clerk.com is remarkable – it's far more than mere assistance. The shared eagerness between both parties to continue progressing their platform further has been amazing!
---
# Passwordless Authentication: Which Option Is Right for Your App
URL: https://clerk.com/blog/passwordless-authentication.md
Date: 2022-09-06
Category: Insights
Description: Passwordless Authentication is on an upward trajectory thanks to advancements in this space and recent password breaches.
## The Case for Passwordless Authentication
Password-based authentication systems are prone to various cyberattacks, including brute-force methods, phishing, and keylogging. In 2021, over [two billion passwords were leaked](https://www.techradar.com/news/over-two-billion-passwords-were-leaked-by-hackers-in-2021) by attackers. The number of stolen passwords has increased by [more than 35 percent](https://www.techradar.com/news/over-two-billion-passwords-were-leaked-by-hackers-in-2021#:~:text=What%E2%80%99s%20more%2C%20the%20two%20billion%20is%20an%20increase%20of%20more%20than%20a%20third%20\(35%25\)%2C%20compared%20to%20just%20two%20years%20ago) in recent years, proving how insecure password-based systems are (hint: something passwordless authentication can help with).
Even though applications encourage users to change passwords regularly and use complex and hard-to-guess phrases, it's inconvenient for users. Most users tend to choose a password that's easy to remember and, therefore, less secure.
This is where **passwordless authentication** can help. Passwordless authentication is the process of authenticating without needing to input a password or any memorized secret to gain access, in turn reducing data breaches. According to Verizon's Data Breach Investigations Report (DBIR), [over 80 percent of data breaches](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends)) happen due to stolen or weak passwords.
Passwordless authentication systems come in several different types, including biometric authentication, one-time passcodes, magic links, and social logins; and each has its own advantages and disadvantages. For instance, if you have a web application, biometric authentication or USB-based authentication might not be the best system since you'll need external devices for verification. In such cases, other authentication types, like social logins or magic links, make more sense.
In this roundup, you'll learn about different types of passwordless authentication that are currently available. You'll look at these options and compare them based on their well-supported standards, convenience, security, and promising new technologies.
### Different Types of Passwordless Authentication
As mentioned previously, passwordless authentication can mean using either a one-time passcode, magic link, or physical hard disk to give you access to the application. In the following section, you'll learn about different types of passwordless authentication, including their advantages and disadvantages.
### Magic Links
[Magic links](/features/email-magic-links) are currently a popular passwordless authentication approach that generates a one-time link and sends it to the user. If the link token verifies with the token stored in the database, the user gets access to the application. The basic workflow looks like this:
In this workflow, a user may enter their email, username, or any specific identifier. The application generates and stores tokens if the user exists on the database and sends a link to the user's email. When the user opens the magic link, the token retrieved from the link gets verified with the backend, and if the token matches, the user gains access to the application. The link stays valid for a specific amount of time, and a user will need to request a new link if it doesn't get authenticated within the allotted time frame.
This workflow may sound simple, but behind the scenes, several complex tasks are happening to ensure that an attacker can be prevented from maliciously accessing the links.
### Benefits of Magic Links
When users need to log in infrequently, magic links provide a frictionless experience that leads to a better user experience. In addition, since no password is stored in a database, there's no chance of a password breach, and the risk of a data breach is also reduced significantly.
On average, an enterprise spends[ $70 USD per password reset](https://bioconnect.com/2021/12/08/are-password-resets-costing-your-company). Large organizations in the US allocate almost a million dollars yearly for password-related support costs. With magic links, since no password is attached to the authentication system, there is no need to implement a password-reset solution or a support team.
### Disadvantages of Magic Links
Even though magic links provide significant benefits, there are also some dependency issues to take into consideration. For instance, if the user's email account gets compromised, the attacker can easily access all applications that authenticate with magic links and use the compromised email to gain access.
With magic links, you also have to worry about email deliverability. Since magic links depend on the user's email, if the email provider is down or the mailbox storage is full, the magic link will not be delivered. In this case, the user won't be able to log in until the mailbox is cleared or the email provider is up again.
In addition, large business-to-business (B2B) companies tend to filter their incoming emails strongly. That means it's possible that a magic link may land in a user's spam folder and affect the overall user experience.
If your application is smaller in size and the frequency of login is fewer, [magic link authentication](/blog/magic-links) can benefit you. But if a large set audience uses your application and it's essential to efficiently log into the application, you should provide multiple authentication options, like a social login or a password-based login, along with magic links.
### Email and SMS One-Time Passcodes
One-time password (OTP) authentication is another type of authentication that many modern applications use. This type of authentication sends a passcode (primarily numeric) to the user's registered email or mobile phone. After sending the passcode, the application then asks for the passcode. If the user provides the correct passcode, they can access the application.
OTPs are time-based (just like magic links), and they stay valid for a particular amount of time. After that time frame, a new OTP will need to be generated if the user wants access to the application.
### Pros of OTP
A [replay attack](https://en.wikipedia.org/wiki/Replay_attack) is a form of network attack in which legitimate data transmission is purposefully or fraudulently duplicated or delayed. Since no password is required in OTP-based authentication and a new OTP is required every time you log in, this type of authentication is safe from replay attacks.
In addition, because OTP-based authentication is provided by most authentication service providers, it's easy to adopt using an authentication service provider like [Clerk](/). And since no password is involved in authenticating a user, the user doesn't have to remember a password, creating a better user experience.
### Cons of OTP
One of the cons of using OTP is that the messages sent to mobile phones are unencrypted. If the phone or the email address gets compromised, an attacker can easily access the application with the user's profile.
You're also dependent on the network when using OTP. Mobile phone networks might not be stable everywhere and if there's a mobile network issue, the passcode may not get delivered to the user. This can also occur with email if the email provider is down.
Another drawback is that you have to share your mobile number with the application you use. This might be inconvenient and cause issues if your bank account is linked to the same number. Moreover, the provider might call or send the user spam messages; in addition, there is the risk of a data leak. If an attacker gets access to the database, the mobile numbers of all customers can get breached.
The issues with email OTP are similar to the problems associated with magic links. Overall, OTP-based authentication has a few drawbacks, which can be an issue considering there's only one layer of protection. However, your application can be heavily secured using OTP-based authentication as a second layer. For example, with password-based authentication, the chance of getting hacked will be significantly reduced if you integrate OTP as well.
### Social Logins
[Social login or social sign-in](/docs/authentication/social-connections/overview#social-connections-authentication-providers) is a type of login where the user logs in with an existing social account. For example, users can use their Google or Facebook credentials to log into an application, simplifying the login process.
### Benefits of the Social Sign-In
One of the benefits of the social sign-in is that the user doesn't have to fill out a registration form and enter details manually. Instead, when registering with a social sign-in, the necessary details are fetched from the social account. This creates a better user experience.
Another benefit of the social login is that the application can collect more information about the user. This information can be used to provide a better and more personalized experience. In addition, using a social login with familiar login identities helps the user perform login efficiently. Users are already familiar with services like Facebook, Google, and GitHub. Seeing a familiar logo and logging in with the social credentials help the user log in quickly.
### Disadvantages of the Social Login
One of the disadvantages of the social login is the lack of trust. If users don't trust your application, they might hesitate to share their social details.
In addition, if your application uses social login, then you give the user's control to a third party. If the social platform decides to shut its service or something else happens, your users won't be able to log into your application.
There's also a chance that the user is not providing accurate information on their social profile. In such a case, the application will receive false information about the user, which can lead to a poor user experience.
Social logins can provide a great solution if your application depends heavily on user customization. The data received from the social platform will be helpful for creating a custom experience. But this depends on the niche of your application. If your application is built for more professionals or older adults, this login solution might not be the right solution for your users. However, you could combine a social login with a traditional login system, and you can let the user decide which solution they prefer.
### WebAuthn
The [World Wide Web Consortium](https://en.wikipedia.org/wiki/World_Wide_Web_Consortium) (W3C) and [FIDO](https://fidoalliance.org) published the WebAuthn standard in 2016. It's a technology that focuses on securing private information. Rather than using a traditional password-based authentication system, WebAuthn uses [asymmetric cryptography](https://www.techtarget.com/searchsecurity/definition/asymmetric-cryptography) to secure a user's account.
When a user tries to log into your application, the server sends a challenge to the user. After completing the challenge, the user can access the application. The challenge can be solved by the server's approved method. Most of the browsers and operating systems are building native support for WebAuthn. You can see how WebAuthn works from their [official site](https://webauthn.io).
### Benefits of WebAuthn
One of the benefits of WebAuthn is its native support. WebAuthn continues to gain popularity, which means browsers and operating systems are continuously trying to provide native support. API and JavaScript functions (on most major browsers) are also available using WebAuthn.
Because WebAuthn uses public and private key encryption, it's more secure than a traditional password-based system. WebAuthn also doesn't require any password, and because of this, the chance of phishing or man-in-the-middle attack is reduced significantly.
### Disadvantages of WebAuthn
One of the disadvantages of WebAuthn is the lack of currently available support. Because the WebAuthn authentication system is new, not every browser or operating system natively supports it. However, this is rapidly changing, as most modern browsers are integrating the WebAuthn API.
WebAuthn can also be used with hardware authenticators like [YubiKey](https://www.yubico.com). But in such a case, if the device gets stolen or lost, the recovery might be tricky if there is no proper setup implemented. In addition, because WebAuthn is in a very primitive stage, the [user experience of using WebAuthn](https://blog.silverorange.com/web-authn-ux) is lacking and, at times, can feel too technical to use.
WebAuthn is an excellent alternative to traditional systems, but implementing it for a simple and small application might be overkill. It's ideal for large-scale applications that focus on privacy.
### SAML Login
Security Assertion Markup Language (SAML) is an XML-based open standard that transfers data between two parties. You can access all other services linked to your identity by logging into only one platform or dashboard. SAML transfers data between an identity provider and a service provider. The identity provider provides the user's identity and authorizes the service provider. The service provider, based on the identity provider, grants access to the user for the service.
SAML is primarily used in B2B use cases. For example, your company email might let you log into a specific dashboard from which you can access other services.
### Benefits of SAML
One of the benefits of SAML is that it provides a great user experience. Only a single credential is needed to log into different applications.
Security is another critical benefit of using SAML. It provides a single point of authentication, and the user's information doesn't leave the firewall boundary. All the different applications don't need to synchronize information between them, making the authentication system securer.
In addition, SAML is widely accepted by enterprises. It has been on the market for a long time and has gained the trust of enterprises.
### Disadvantages of SAML
One of the disadvantages of SAML is that it can be vulnerable to XML and DNS spoofing attacks, which makes the system less secure.
It's not suitable for personal applications like social platforms since setting up SAML is difficult; however, it works well for enterprise applications because employees won't need to think of multiple software that the company uses. Using a single set of login credentials, your employees can access all your software.
In addition, implementing SAML is a critical job. Different security aspects need to be considered, which might not be an easy job for a small-sized team.
### Conclusion
Passwordless authentication is gaining more attraction because it's an excellent solution for providing a better user experience and increased security to your users. In this article, you learned about different popular passwordless systems and their benefits and disadvantages.
[Passwordless authentication](/docs/authentication/configuration/sign-up-sign-in-options#authentication-strategies) can be an excellent solution for your application, but it's crucial that you understand the use case and implement a solution suitable to your needs. [Try Clerk free today](https://dashboard.clerk.com/sign-up) to add passwordless authentication to your application within minutes – not weeks.
---
# What are Webhooks? The Ultimate Guide
URL: https://clerk.com/blog/what-are-webhooks.md
Date: 2022-08-19
Category: Insights
Description: Webhooks allow apps to communicate with one another. Find out best practices and more here.
**What are Webhooks? The Ultimate Guide**
Webhooks can be powerful tools for your business, but only if implemented correctly. In this blog post, you will learn the nature of webhooks, some of the webhook best practices for implementation, and their various use cases in a business.
You will also get to explore examples of platforms that use webhooks in their development processes. And finally, you will learn how to implement webhooks in your authentication and development strategies. By following these webhook best practices, you will ensure that your webhooks are secure and efficient.
## **What Are Webhooks?**
Webhooks are user-defined HTTP callbacks initiated by an event. In other words, a webhook is an HTTPS POST request sent whenever a specific event occurs to a URL that you have specified.
The usual trigger is some event, such as pushing code to a repository or a comment being posted to a blog. When that event occurs, the source site makes an HTTP request to the URL configured for the webhook. Webhooks can be used to perform various tasks, such as building a continuous integration system, sending notifications, or synchronizing data.
Webhooks offer a simple and flexible way to automate tasks that would otherwise be repetitive and time-consuming. They are preferred over polling because they allow you to receive information in near-real-time instead of waiting for a set interval. Their usage is not limited to development tasks; webhooks can be used for a wide range of integrations, such as social media, marketing, and customer support.
Webhooks are a powerful tool that can automatically send information from one system to another. However, before implementing webhooks in your system, it is essential to consider a few webhook best practices.
## **How Does a Webhook Work?**
So, how do webhooks work? A [webhook is an HTTP](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-webhooks) callback that is triggered by an event. When that event occurs, the source site makes an HTTP request to the configured webhook URL. Developers use webhooks to receive notifications about events within their applications. For example, a developer could use a webhook to be notified when a new user signs up for their service.
The webhook request will typically contain information about the event that triggered it. This information can be used to take action within the receiving application, such as updating a database or sending a notification. In some cases, the webhook may also trigger an action on the source site. For example, a webhook could be used to deploy application code when it is pushed to a repository automatically.
## **Best Practices When Implementing Webhooks**
Webhooks are a great way to get real-time data from your web application. They are perfect for automating tasks or getting notified when something happens in your app. Webhook traffic is described as a request that is initiated by an event. The request is then forwarded to the URL that you have configured for the webhook.
However, to reliably and efficiently use webhooks, there are some best practices to keep in mind when setting them up. The webhook best practices will ensure that your webhooks are working as intended and that you are getting the most out of them. When configuring webhooks for your application, security should be your top priority. Here are some best practices to follow when implementing webhooks:
### **Provide Developers With Sample Code to Authenticate Webhook Requests**
One of the most important things to do when setting up webhooks is to provide developers with sample code to authenticate webhook requests. This will ensure that only legitimate requests are processed and that any malicious requests are ignored.
There are a few different ways to authenticate webhook requests. The most common method is to use a shared secret. This is a piece of data known only to the server and the client. When a webhook request is made, the shared secret is used to calculate a hash. This hash is then compared to the one sent with the request. If they match, then the request is considered to be authentic.
Another method that can be used to authenticate webhook requests is to sign them with a digital signature. This signature is generated using a private key that is known only to the server. The client then verifies the signature using the server's public key. This method is more secure than using a shared secret, but it is also more complicated to set up.
Webhooks are incredibly powerful tools that enable your application to receive real-time updates from other applications or services. However, because webhooks involve sending potentially sensitive data over the internet, it's essential to take steps to ensure that your webhook endpoints are as secure.
### **Keep Your Webhook Endpoints Secure**
Webhook endpoints are URLs configured on a system to receive data sent by an HTTP callback. Webhook endpoints are [a potential attack vector](https://docs.oracle.com/en/cloud/paas/content-cloud/solutions/use-webhooks.html#GUID-3513A92A-1E36-4E47-B5C7-7D8989590AF1) for malicious actors. If an attacker can guess or brute force the URL of a webhook endpoint, a request can be sent to that endpoint and potentially cause damage.
As a preventative measure, it is crucial to keep your webhook endpoints secure. One way to do this is to use a randomly generated string as the endpoint URL. This will make it much harder for an attacker to guess the URL of the endpoint.
Another way to keep your webhook endpoint secure is to use HTTPS for all communication. This will ensure that all the webhook payload passing between the server and the client is encrypted. It also prevents anyone from eavesdropping on the transmission and potentially intercepting sensitive data.
The third step is consumer verification of the client before processing any requests. This can be done using a shared secret or a digital signature. Whichever method you choose, make sure that it is secure and that only trusted clients are able to access your webhook endpoint.
### **Configure To Receive Specific Webhook Events**
When configuring your webhooks, you should only receive the business process events in which you are interested. There is no need to receive all events for all of your users as it will just result in extra work for you and could lead to missed events if you are not paying attention.
Instead, only configure your webhooks to receive the specific events in which you have interest. This way, you can be sure that you will only receive the events that you care about and that you will be able to process them in a timely manner.
### **Utilize the Network Time Protocol To Prevent Replay Attacks**
Another critical webhook best practice when setting up is to utilize the Network Time Protocol (NTP). This protocol is used to [synchronize the clocks](https://www.ibm.com/docs/en/aix/7.1?topic=files-network-time-protocol-ntp) of computers over a network.
Using NTP will help to prevent replay attacks. A replay attack is where an attacker intercepts a webhook request and then re-sends it at a later time. If the clocks on the server and the client are not synchronized, the attacker could potentially resend the request before it has been processed. This could lead to the same event being processed more than once.
By using NTP, you can be sure that the clocks on the server and the client are synchronized. This will prevent replay attacks and ensure that each webhook request is processed only once. The use of NTP is vital when processing time-sensitive data.
### **Pay Attention to Delivery Attempt Data and Metrics**
When setting up webhooks, paying attention to the delivery attempt data and metrics is essential. This data can be used to troubleshoot any problems you are having with webhooks. Delivery attempt data is defined as information about each time webhook notifications are sent from the server to the client.
This data can be used to determine if there are any problems with the connection between the server and the client. It can also be used to determine if there are any problems with the webhook endpoint itself by reviewing already-logged events.
By paying attention to this data, you can be sure that your webhooks are being delivered successfully. This will help to prevent any missed events and ensure that your webhooks are working as intended. The delivery attempt data will tell you how many times a webhook request has been made and whether or not it was successful. This data can be used to identify any problems with the webhooks.
The webhook metrics will tell you how long it is taking for the webhook requests to be processed. This information can be used to identify any error in the system. By paying attention to the delivery attempt data and metrics, you can be sure that your webhooks are working correctly and that they are being processed promptly.
## **Why Do We Use Webhooks**
Now that we have covered some of the webhook best practices for configuration, let's take a look at why we use them. Webhooks are a great way to get real-time data from an external source. They are also a good way to keep your own internal data up-to-date.
For example, let's say that you have a website that sells products. Every time a product is sold, you could use a webhook to send the order information to your internal system. The information received from the website could then be used to update the inventory in your internal system. This would ensure that your inventory is always up-to-date.
Another example of why webhooks are useful is if you have a blog. Every time a new post is published, a webhook could be used to send the information to your mailing list. This would ensure that your subscribers are always updated on the latest posts.
Webhooks are also a good way to get real-time data from an external source. For example, let's say that you want to track the stock price of a company. You could use a webhook to get the information from an external source and then display it on your website. This would allow you to get the latest information without constantly refreshing the page. The following text describes two major ways on how to use webhooks.
### **To Receive Different Event Types**
Webhooks are essential to receive different event types. Events are defined as any actions that take place on your website or application.
Some examples of events include:
- A user signs up for an account
- A user adds an item to their shopping cart
- A user completes a purchase
If you are not using webhooks, then you will not be able to receive these events in real-time. For example, let's say that you have a web application that allows users to sign up for an account. Whenever a user signs up for an account, you could use a webhook to send an email to the user. This would allow you to receive different event types and take action based on those events.
### **To Store Information Securely**
Webhooks can also be used to store information securely. For example, let's say that you have a web application that allows users to input sensitive information. You could use a webhook to send that information to your internal system. This would allow you to store the information securely and not have to worry about it being intercepted by an attacker.
## **Authentication With Webhooks**
Another best practice when setting up webhooks is to use authentication. When you use authentication, you can be sure that only authorized users are able to access the data.
There are many[ different ways to authenticate](https://developer.zendesk.com/documentation/event-connectors/webhooks/webhook-security-and-authentication/#:~:text=Webhooks%20support%20two%20types%20of,authentication%20property%20from%20the%20request.) with webhooks. One popular way is to use an authentication tokens system. With this system, you would generate a token for each user. The user would then include the token in the webhook request. This would allow you to verify that the user is authorized to access the data.
Another way to authenticate with webhooks is to use an application programming interface (API) secret key. The API secrets would be used to sign each webhook request. This would allow you to verify that the request came from a trusted source.
## **Examples of Platforms That Use Webhooks in Their Development Process**
Many platforms use webhooks in their development process to achieve different goals. The following are some examples and use cases of webhooks explained.
### **Shopify**
Shopify is a popular e-commerce platform. Shopify uses webhooks to[ keep track of events](https://shopify.dev/api/admin-rest/2022-04/resources/webhook#top) that happen on the platform. When a customer makes a purchase, Shopify uses a webhook to send the order information to the merchant. This allows the merchant to keep track of their sales and fulfill their orders on time.
Shopify also uses webhooks to keep apps in sync with shop data or perform an action after a specific event occurs. Webhooks are a more efficient alternative to constantly polling for changes to data via an API server.
### **Discord**
Discord is a voice, video, and text chat app. It uses webhooks to[ send messages and data updates](https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks) to a text channel in your server. By creating a webhook endpoint in your server, you'll generate a webhook URL that you can drop into a number of other services to link the two.
For example, you could set up a webhook endpoint in your server to send a message to a Discord channel whenever someone made a post on your blog. Or, you could use a webhook to automatically keep a channel in your Discord server updated with the latest sports scores.
### **Mailchimp**
Mailchimp is a popular email marketing platform. Mailchimp uses webhooks to[ keep track of events](https://mailchimp.com/developer/marketing/guides/sync-audience-data-webhooks) that happen on the platform. Mailchimp uses a webhook to send the subscription information to the list owner when a user subscribes to a list.
Webhooks are also helpful tools that can be used to collect information about audience changes in Mailchimp as they happen. By entering a valid URL that is set up to accept HTTPS POST requests, you can receive updates on subscriptions, changed email addresses, campaign sending, and more. Webhook can also be used to keep your client's profile data in sync with your database, detect when an email address starts bouncing, or alert your application when a campaign has finished sending.
## **How You Can Implement Webhooks Into Your Authentication or Development Strategies**
Now that you know what webhooks are and how they can be used, you may be wondering how you can implement them into your authentication or development strategies.
One way to use webhooks is to set up a webhook endpoint in your server. This endpoint would be responsible for handling all webhook requests. The endpoint would need to be able to authenticate the request and process the data. Once the request is authenticated, the endpoint will take the appropriate action.
Another way to use webhooks is to use them as part of your authentication strategy. Webhooks can be used to verify that a user is authorized to access data. One way to do this is to use a secret key. The secret key would be used to sign each webhook request allowing you to verify that the request came from a trusted source.
If you're looking for a[ flexible, multi-factor authentication service](/features/multifactor-authentication) that can easily integrate with your webhook endpoints, Clerk is here to help. Clerk is the leading authentication and authorization services provider in the industry. [Try Clerk for free today](https://dashboard.clerk.com/sign-up) and learn how to implement authentication into your security strategy.
---
# What Is an SDK and How Is It Different From APIs?
URL: https://clerk.com/blog/sdk-vs-api.md
Date: 2022-08-10
Category: Insights
Description: While an SDK and an API often work together in the software development process, they each serve a different function. Find out what that is here.
Modern software development typically involves using both software development kits (SDKs) and application programming interfaces (APIs). Even people with experience in the world of application development get tripped up over the fundamental difference between both sets of tools. Both help users improve the functionality of their applications quickly without having to construct something from the ground up. Let’s look at the core differences between SDKs vs. APIs and how they enhance the development experience.
## **What Is an SDK?**
An SDK is often referred to as a dev kit. It’s a set of software-building tools made available from vendors. Developers usually rely on SDKs to build applications using a specific programming language targeted at a particular system or platform. An example of that would be the Windows SDK managed by Microsoft, which contains various frameworks for creating applications that run on Windows computers.
An SDK makes it easier for developers to create applications that follow a standardized pattern for a specific environment. Users download the kit and other components, like prebuilt application examples and instructions. SDKs give you a head-start on building, testing, and deploying a robust application.
## **What Is an API?**
An API is a mechanism that helps two software modules communicate using specific protocols and definitions. It's a piece of software designed to fulfill a particular function. The weather app on your phone and the GPS application providing directions are examples of APIs.
The interface part of an API outlines the contract used between two applications attempting to speak to each other. Your API defines the request and response format used between the two. Developers can refer to the documentation for APIs to understand how they can set up requests and responses within applications built using an SDK.
### **How APIs Work**
The architecture of your standard API typically consists of client and server functions. An application making a request is the client, while the one providing the response is the server. Your weather app calls the weather service database, asking for information, and the database provides information about the atmosphere in your specific location.
Below is an overview of different APIs:
- **SOAP:** The Simple Object Access Protocol exchanges messages between clients and servers using an Extensible Markup Language (XML) format. The format became popular among developers in the past. The biggest drawback is the lack of flexibility in structuring requests and responses.
- **RPC:** Remote procedure calls ask the client to execute a function, called a procedure, from a server. That server processes the output and sends it back to the client.
- **REST:** Representational state transfer APIs define functions used by clients to access data from a server. Both clients and servers use HTTP to exchange information. REST APIs do not preserve data between client/server requests. Responses from servers are sent using plain data.
- **WebSocket:** Instead of XML, WebSocket APIs rely on JavaScript Object Notation (JSON) to pass data back and forth. It’s a more modern approach that allows for two-way communication between clients and servers. The ability for servers to send callback messages to connected clients increases its efficiency versus REST APIs.
## **How a Software Development Kit Differs From an Application Programming Interface**
The most significant difference between an SDK vs. an API is in how they enable development. Your SDK provides the building blocks you need to write new programs designed for specific platforms using your preferred programming language. There’s often at least one API included with most SDKs. Everything you need to construct a basic app comes with an SDK.
Developers can’t use APIs to build brand-new applications. However, they do allow applications to work together to enhance various aspects of your applications. For example, you can use an API to pull financial data and feed it into a dashboard featured on a website.
## **Common SDK Features**
Let’s look at features that are often included when you download an SDK.
### **Integrated Development Environment**
An integrated development environment (IDE) is used for creating various applications. The platform brings together numerous tools that developers rely on with one graphical user interface (GUI). Here’s a breakdown of the components of a typical IDE:
- **Source-code editor:** Developers use this screen to write software code. A source-code editor often comes with options to highlight specific syntax, point out bugs, and auto-complete phrases in lines of code to help speed up development.
- **Build automation:** This utility automates tasks used to set up local software builds for a developer. Build automation performs functions like packaging binary code and running automated tests.
- **Toolbar:** An IDE toolbar resembles one found in a word processor. It organizes different components that developers rely on as they are writing code.
IDEs help enhance a software engineer’s productivity thanks to the way they standardize the configuration of various developer tools. Everything you need is available through one interface.
### **Debuggers**
A debugger is a computer program that tests and finds bugs within a developer’s code. The debugger typically starts working as soon as you begin writing your code. As you compile your code and integrate it with other programming components, your debugger will highlight errors that keep the program from running correctly. Debuggers are essential to the development process, especially if you’re working on an application containing thousands of lines of code. You can also integrate unit testing to make things easier.
### **Code Samples**
Code samples show developers how to implement different programming scenarios or concepts. They’re also helpful in showing you how to set up more complex architecture components, like a grid. Many SDKs provide you with complete applications and the source files needed to run the program.
### **Code Libraries**
One of the main rules that programmers follow is "Don’t Repeat Yourself," or DRY. Code libraries help you stick by that principle by providing prewritten code that you can modify. These reusable blocks of code make it easy to save time while building projects or optimizing other pieces of your program. Another advantage of using tested code libraries is that they add stability to your application.
### **Documentation**
The documentation that comes with SDKs provides you with instructions on using each component and integrating it with other systems.
### **APIs**
APIs that come with SDKs contain libraries built using the platform’s core language. You can use your SDK to leverage APIs that add more capabilities to your program.
## **The Benefits of an SDK for Software Developers**
SDKs make your job as a developer more straightforward by making it easier to pull different components together to construct an application. They make integrating standard processes easier and allow you to access pertinent information while coding. Many SDKs come with built-in support and documentation to help you leverage the program effectively.
### **Enhanced Control of User Interface and User Experience**
An SDK gives you more control over the elements used to build your user interface. If a customer wants components laid out in a certain way, you can follow their requirements seamlessly with an SDK versus trying to use a basic code editor and disparate libraries. You’ll also have an easier time testing each screen element and ensuring that the users will be happy with the final product.
### **Quicker Time to Market**
The code samples provided with SDKs allow you to create or expand the functionality of your applications quickly. You can leverage APIs and other libraries to quickly set up new components for your program. That makes the application easier to debug, test, and deploy in different environments before you release it for general use.
### **Broader Integration Options for Existing Tech Stack**
With more vendors choosing to integrate APIs into their SDKs, there are more integration options available for developers. For example, if you have an application built using the .Net framework, you can still integrate the SDK with other frameworks to enhance the look of your UI.
## **Types of and Common Uses for Development Kits**
While some SDKs enable connections between different tools, others help your applications run on specific devices and operating systems.
### **SDKs by Hardware**
Many hardware providers make SDKs available to developers for programming technology like the Internet of Things (IoT) or programming robots. Having an SDK readily available for specific hardware makes it easier for developers to start their coding.
### **Open-Source SDKs**
While most SDKs come from specific vendors, you can find open-source SDKs that allow developers to modify the underlying source code. However, there can be security risks associated with working with an unsupported platform.
### **Proprietary SDKs**
In contrast to open-source SDKs, developers can’t access and modify proprietary source code. Instead, they must purchase a license permitting them to use proprietary code elements.
### **SDKs for Each Programming Language**
Below are examples of SDKs available for different programming languages:
#### **C#**
- [.NET SDK](https://docs.microsoft.com/en-us/dotnet/core/sdk)
- [Twilio SDK](https://www.twilio.com/docs/libraries/csharp-dotnet)
- [AWS SDK for .Net](https://aws.amazon.com/sdk-for-net)
- [EOS SDK for C#](https://dev.epicgames.com/docs/services/en-US/GameServices/CSharpGettingStarted)
#### **JavaScript**
- [Facebook SDK](https://developers.facebook.com/docs/javascript)
- [AWS SDK for JavaScript](https://aws.amazon.com/sdk-for-javascript)
- [Google Maps SDK](https://developers.google.com/maps/documentation/javascript/overview)
#### **Java**
- [Oracle SDK](https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/javasdk.htm)
- [AWS SDK for Java](https://aws.amazon.com/sdk-for-java)
#### **Python**
- [Carto Python SDK](https://carto.com/developers/python-sdk)
- [Square Developer Python SDK](https://developer.squareup.com/docs/sdks/python)
- [Smartling Python SDK](https://help.smartling.com/hc/en-us/articles/4412947322267-Python-SDK)
#### **Ruby**
- [AWS SDK for Ruby](https://aws.amazon.com/sdk-for-ruby)
- [Oracle SDK for Ruby](https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/rubysdk.htm)
- [DocuSign SDK for Ruby](https://developers.docusign.com/docs/esign-rest-api/sdks/ruby)
## **Do You Need Both an API and an SDK for Development?**
It’s possible to build applications using an SDK without relying on APIs. However, working with APIs and SDKs together helps enhance the programming experience. It’s easier to construct platforms that meet your requirements. There are SDKs available for both Apple and Android developers who want to create mobile apps for those environments.
You don’t have to think of it as a choice between using either an SDK or an API. Remember, many SDKs come with preinstalled APIs. If you want to build a website that allows users to sign in through their Facebook account, an SDK makes that much easier.
You can automate user verification using the Facebook Graph API. That way, you, as the developer, don’t have to go through the trouble of figuring out how to generate tokens, inspect them, and determine which app the user is trying to connect through. The API makes the sign-in process for your app seamless.
### **Benefits of SDKs**
SDKs help developers quickly add functionality to their applications and construct standard components. Typically, there’s no need to integrate an SDK with other elements. If you do, that might slow down your development process.
Most software engineers rely on SDKs to complete simple functions like allowing users to make mobile payments or setting up location services. Certain SDKs let you do more complex programming, like creating virtual reality (VR) and augmented reality (AR) programs.
When used correctly, SDKs help relieve the back-end burden of building software programs. You have a modular foundation to rely on that saves you much of the manual effort. Many of the apps created by software engineers contain a few features that serve a common purpose.
For example, a telemedicine app might offer chat features that let users reach out to medical professionals with questions or concerns. A mobile insurance app would contain features that allow users to check on a claim payment's status or print out a copy of their insurance card.
The efficiency provided by an SDK makes it easier for dev team members to work independently. It limits the number of common touchpoints, decreasing the risk of one person breaking another team member’s code during an update.
Adding APIs into the mix cuts down on lag time because of the research needed to figure out how to build a new capability. Working with an API means developers have to worry only about the necessary pieces that make their application work the way they want it to, eliminating the need to dive into how everything works under the surface.
## **Other SDK Considerations**
Some SDKs have agreements to which you must provide consent before you are allowed to use the software. Vendors often make new versions of SDKs available for alpha or beta testing, meaning they are not yet publicly available. Those features you try out could undergo modifications or changes before the SDK’s general release. Certain features may fall under a license agreement, so you have to be careful that you do not develop a project that falls outside of its scope.
Read through all the documentation of any SDK you want to use and make sure there is nothing that conflicts with your desired usage. You can’t develop proprietary apps using an SDK with a General Public License. You should also look for any constraints around SDKs that come with a Lesser General Public License (LGPL) if you intend to build a project containing proprietary elements. Think about the ease of implementing security features like multifactor authentication.
### **Commercial vs. Open Source**
Organizations also have to think about the cost of using an SDK. Many are tempted to use open-source SDKs because they’re free. However, your company could still end up paying if there’s a need for developers to spend hours getting up to speed on how the software functions. The cost of the time lost trying to figure out how an open-source SDK works could exceed what you might pay for a licensed version.
Commercial products do bring expenses associated with paying for licenses and integrating the components into current applications. However, you can turn to the vendor for support when you have questions. Paid SDKs tend to be more secure, which lowers the risk of your SDK becoming a gateway for a cyberattack.
You also have to think about the ease of using the SDK in your development shop. The goal of an SDK is to make coding easier. If you’re spending more time getting the application to function correctly than building software, there's a problem. Think carefully about implementing an open-source SDK. If your company has knowledgeable staff who are comfortable working with the product and bringing other developers along, you can succeed.
Usability is often the most significant advantage commercial products have over open-source SDKs. Even if you have developers who are capable of leveraging an open-source SDK, you have to think about who might be asked to maintain those applications if they end up moving on to another position or leaving the organization. How easy will it be to bring other software engineers up to speed on the SDK?
You should also look at the support provided by the SDK manufacturer. With open-source SDKs, there may be only online communities to turn to instead of a fully knowledgeable staff. If you have questions, there’s no guarantee that you’ll get timely answers or that there will be someone available who can help.
## **A Roundup of SDKs vs. APIs**
SDKs provide developers with everything necessary to create or modify applications. Many come with prebuilt code that helps software engineers get started on their applications. APIs create connections between two applications and allow developers to expand the functionality available within a program.
It’s easier for developers to become more efficient by using SDKs and APIs together. When deciding on an SDK, look at whether you’re really saving by going with an open-source version when it comes to the cost, time, and effort. If your development team is unfamiliar with the platform, you could lose time and money trying to adapt.
Make sure that your SDK does not come with license restrictions that would impact your development. Explore the support that would be available to you or your dev team if you were to run into problems with your SDK.
***Ready to implement your own authentication?***
Clerk has been built with developers in mind and allows you to add authentication to your application with just a few lines of code. [Get started for free today](https://dashboard.clerk.com/sign-up)!
---
# User Management and How It Relates to Authentication
URL: https://clerk.com/blog/user-management-in-authentication.md
Date: 2022-08-03
Category: Insights
Description: User management assists in authenticating and storing users. Find out more about it here.
**User Management and How It Relates to Authentication**
User management identifies and authorizes users in order to provide secure access to digital resources. This process usually involves an authentication procedure that confirms the user's identity without revealing the password. This article discusses user management and authentication in detail.
You will learn what user management is and how it relates to authentication. Additionally, you will look at different types of authentication and how they are used in user management systems. Finally, you will take a closer look at traditional approaches to user management versus real-time approaches. Read on to learn more!
## **What Is User Management?**
User access management is [the process of identifying, authorizing and authenticating users](https://cloud.ibm.com/apidocs/user-management) on authorization platforms. This process usually starts with user registration, where the user provides their personal information. Once the user is registered, they can sign in to the platform. During sign-in, the user's identity is confirmed, and they are given access to the platform.
User management has four main aspects: user profiles, user properties, user privileges, and user migration.
### **User Profiles**
User profiles contain the user's personal information, such as user names, contact details, and photograph. This information is used to identify individual users and is usually stored in a database. User profiles can also contain other information, such as user creation method, and users' preferences and interests.
### **User Properties**
User properties are specific attributes assigned to individual users that identify them within the system. These attributes can include the user's name, contact information, and role within the company. User properties can be static, such as individual user type (e.g. administrator, user, guest), or dynamic, such as a user's current status (e.g. active, inactive, suspended). User properties are used to identify users within the system.
### **User Privileges**
A user privilege, on the other hand, is a permission that allows a user to perform certain actions, such as creating new users or accessing restricted areas of the system. For example, a user might be given the privilege to view customer data or to create new categories in the product database. User privileges define custom user roles i.e., what a user can do and are used to control user's level of access within the user interface.
### **User Migration**
User migration is the process of moving user data from one platform to another. This is usually done when users change the user type or are deleted from the system. User migration can be a complex process, depending on the size and complexity of the user data.
## **Benefits of a User Management API**
A user management API (Application Programming Interface) [is a set of software instructions that allow one application to interact with another](https://www.forbes.com/sites/moorinsights/2020/08/06/for-devops-application-programming-integration-api-is-a-major-security-vulnerability/?sh=79fdba931f20). An API can be used to create, read, update and delete user profiles. It can also be used to manage user access and privileges.
Using an API to manage users has many benefits, including:
### **Ability To Manage User Identities and User Access**
API-based user access management allows you to manage users and their access to your platform from a central location. This means that you can easily add, remove or update user accounts without having to make changes to your code. Additionally, it is easier to keep track of user activity and identify potential security risks.
### **An Enhanced User Experience**
API-based user management can provide a better user experience by allowing users to self-register and sign in using their own social media accounts. This eliminates the need for users to remember multiple usernames and passwords. Additionally, API-based user management enables you to provide a personalized experience for each user by tailoring the content and functionality of your system to their specific needs.
A user access management API provides many other benefits for users and website administrators. For instance, an API can allow user synchronization across multiple devices and platforms. This means that users' preferences and settings can be seamlessly applied without regard to their sign-in location.
In addition, an API can allow you to create custom user roles. This is beneficial for websites that need to give specific users different access levels. Administrators can create a more seamless and user-friendly experience by using a user management API for all users.
### **Compliance With Security Policies**
API-based user access management can help you comply with security policies, such as the EU [General Data Protection Regulation (GDPR](https://gdpr-info.eu) and the [U.S. Privacy Act](https://www.hhs.gov/foia/privacy/index.html#:~:text=The%20Privacy%20Act%20of%201974,other%20identifying%20number%20or%20symbol.). This is because an API allows you to control how your user data is collected, used and stored. Additionally, an API can help you keep track of user activity and identify potential security risks.
### **A Reduction in Password Issues**
API-based user management can help to reduce password issues, such as forgotten passwords and resetting passwords. This is because an API allows you to use various authentication methods, such as social media sign-in or two-factor authentication. Additionally, an API can help you keep track of user activity and identify potential security risks.
## **What Is Authentication and How Does It Relate to User Management Systems?**
Authentication is the [process of verifying the identity of a user](https://www.forbes.com/sites/davidbalaban/2021/07/27/what-is-authentication-and-how-does-it-work/?sh=33d355b7e2bc). This can be done in a variety of ways, including using a username and password, using a biometric identifier, or using a physical token. User management systems are responsible for managing users' identities within small-and medium-sized businesses (SMBs). This includes creating and maintaining user accounts, assigning permissions to users, and resetting passwords.
Identity and access management (IAM) is a term that is often used interchangeably with the user access management system. However, IAM is a more comprehensive term that encompasses [all of the processes and technologies used to manage user identities](https://www.forbes.com/sites/davidbalaban/2021/07/27/what-is-authentication-and-how-does-it-work/?sh=33d355b7e2bc), including authentication.
When it comes to authentication, user management systems and IAM systems are responsible for managing the credentials that users need to access accounts. This includes storing passwords, generating and issuing tokens, and managing the authentication process.
The relationship between authentication and user access management systems is an important one. User access management systems are responsible for managing users' identities, and authentication is responsible for verifying those identities. Without both of these systems in place, it would be impossible to manage user accounts and ensure that only authorized users have access to them.
There are various authentication methods that SMBs can use, and the best method for a given SMB will depend on its specific needs. User management systems and IAM systems can help SMBs choose the suitable authentication method for the identified needs and ensure that users' identities are properly verified.
## **Types of Authentication for a Frictionless Experience**
There are many different types of authentication, each with its strengths and weaknesses. When choosing an authentication method, it is crucial to consider both the user experience and the security of the system.
One of the most common types of user authentication is single-factor authentication. This method relies on a single piece of evidence to verify the user's identity. The typical form of single-factor authentication is a password. While passwords are relatively easy to use, they can be cracked or guessed if they are not strong enough. As a result, many SMBs are moving to two-factor authentication.
Two-factor authentication adds an additional layer of security by requiring two pieces of evidence to verify the user's identity. The most common form of two-factor authentication is a combination of a password and a physical token, such as a key fob or a card.
Two-factor authentication is much more secure than single-factor authentication because it is much harder for an attacker to get both pieces of information. However, it can inconvenience users who for some reason lose access to the chosen second factor.
Biometric user authentication is another user authentication type that is gaining popularity. This method uses physical or behavioral characteristics to verify the user's identity. Common examples of biometric user authentication include the use of fingerprint scanners, and iris or facial recognition to verify user identity and grant access permissions.
Biometric authentication is more secure than other methods, such as passwords, because it is very difficult to fake someone's biometric information. Additionally, biometrics can be used in conjunction with other methods, such as two-factor authentication, to further improve security. Correct system design is critical to a positive user experience.
Another method of authentication is to use a physical token. This can be in the form of a card, a key, or a badge. The user must have the physical token in order to sign-in. This is more secure than password authentication but loss of the token will necessarily result in user inconvenience.
There are many different types of authentication, but not all of them are equally effective. When choosing an authentication method, it is crucial to consider the user experience as well as the security of the system.
## **Traditional Versus Real-Time User Management Approaches**
There are two approaches to user management: traditional and real-time. Traditional user management is the process of creating, storing, and managing user accounts and passwords. Real-time user management is the process of authenticating user accounts in real time, as users request access to resources.
The traditional approach to user management is time-consuming and error-prone. It requires IT staff to manually create user accounts, assign passwords, and keep track of user activity.
This approach is vulnerable to password attacks, such as [brute force and dictionary attacks](https://www.kaspersky.com/resource-center/definitions/brute-force-attack). It is also susceptible to [social engineering attacks,](https://www.itgovernance.co.uk/social-engineering-attacks) where attackers trick users into revealing user names and corresponding access permissions.
The real-time approach to user access management is more efficient and secure. It uses an authentication server to validate user credentials in real-time. This approach eliminates the need to store user passwords, which reduces the risk of password attacks.
This approach eliminates the need to create and manage user accounts manually. It also reduces the risk of password attacks by validating user credentials before storing them on the server.
The real-time approach to user access management is the preferred method for managing user accounts. It is more efficient and secure than the traditional approach.
## **How Authentication Services Aid User Management**
User access management and authentication go hand-in-hand. Authentication services provide the foundation for keeping user data secure, while user access management tools help maintain control over who has access to that data. By integrating these two technologies, small-and medium-sized businesses can increase security and efficiency while reducing the risk of data breaches.
### **Security Settings**
Start-ups can use authentication services to control access to data and applications. By setting up user groups and assigning permissions, administrators can ensure that only authorized users have access to sensitive information. Additionally, platform administrators can use authentication services to track user activity and monitor suspicious behavior.
#### **Password Management**
One of the most critical aspects of user security is password management. Authentication services can help small-and medium-sized businesses enforce strong password policies and prevent users from reusing passwords across different systems. Identity access management services can also provide a single location from which to manage access to your network users' data, making it easier for users to keep track of sign-in information.
#### **Management of Different Devices**
With the rise of mobile and the practice of allowing employees to use their own computers, phones, or other devices for work purposes (BYOD, or bring your own device), it is more important than ever for startups to be able to manage and control access to data from a variety of devices. Authentication services can help by allowing administrators to set up device-specific permissions and enforce security policies. Identity access management services can also offer a centralized platform for controlling and tracking user activity, which makes it much simpler to identify suspicious behavior across multiple devices.
#### **Multi-Factor Authentication**
Another way to improve security is to require users to authenticate with more than one factor. User platforms can employ multi-factor authentication by using a combination of passwords, biometrics, and tokens. By requiring users to provide multiple forms of authentication, SMBs can increase user interface data security and reduce the risk of unauthorized access.
### **User Profile Management**
User profile management is the term used to describe the process of creating and managing user accounts. User management tools can also be used to manage user profiles. This includes setting up new user accounts and managing user permissions, email addresses, social media accounts, and other user-related information.
By centralizing this information, SMBs can reduce the risk of data breaches and make it easier for users to keep track of sign-in information.
#### **Email Address Management**
Small-and medium-sized businesses can employ user access management tools to manage email addresses. This includes verifying, adding, removing, and updating email addresses.
A user management platform needs to be able to handle bounced emails and other problems that can occur with email addresses. Additionally, user access management tools can be used to set up email forwarding and provide a central location for managing email addresses.
#### **Social Sign-in**
Another critical aspect of user management is social sign-in. Social sign-in allows users to sign-in with existing social media accounts instead of creating new ones. User management tools provide a central location for managing social media accounts, i.e., adding, removing, and updating social media accounts related to individual users.
By integrating authentication services and user access management tools, startups can increase security and efficiency while reducing the risk of data breaches. Startups can accomplish a lot with these tools, i.e., control access to data, enforce strong password policies, and require multi-factor authentication.
User management tools can also help manage user profiles and reduce the risk of data breaches. These technologies can help SMBs keep users data safe and secure when used together.
User profile management is a vital part of any platform that relies on central user identity. It would not be easy to control who has access to what resources without proper identity access management.
## **How To Find the Cloud-Based User Management System for You**
Effective user management is a critical part of any business, and it can be challenging to find the right system for your needs. There are a few things to consider when choosing a user management system.
The first question is how many user names you need to manage. You may not need a full-fledged user management system if you only have a small user base.
You'll also want to consider the features that you need in a user interface. Some identity access management systems offer more features than others. If you need specific features in your user interface, you'll want to choose a system that provides them.
Another thing to consider is how easy the system is to use. You'll want to choose a system that is easy to use so that you can manage your users without any problems.
Finally, you'll want to consider the price of the system. User management systems can vary in price, so you'll want to choose one that fits your budget.
You can narrow down your options by considering these factors and find the appropriate user management service provider for your needs, like Clerk.
Clerk provides the tools you need to manage your user identities and access permissions while also enhancing your user experience. With our services, you can rest assured that your authentication process will be smooth and compliant with any security policies you may have in place.
---
# What is Next.js?
URL: https://clerk.com/blog/what-is-nextjs.md
Date: 2022-07-20
Category: Insights
Description: Next.js is a framework in the React ecosystem that is primarily used for developing JavaScript applications. Understand the ins and outs below.
*Updated: 09/01/2022*
Web applications are a fundamental part of the modern internet. As a web developer, you likely spend a lot of time trying to make the development process for these apps simpler and more efficient. That's why you should understand how Next.js works.
Next.js is a popular framework that makes it easier to develop JavaScript applications of all kinds. In this guide, you'll learn the answers to questions like, "What is Next.js?" and, "Why use Next.js?" You’ll also learn about the best use cases for Next.js in your development process. If you're ready to learn more, then let's dive in.
## **What Is Next.js?**
Next.js is a React framework that gives programmers a structured environment to quickly create fast web applications. With Next.js, you can use React’s powerful tools without having to build your application from the ground up.
React is a specific JavaScript library designed to help you develop interactive user interfaces (UIs). On its own, React is a useful tool, but it still requires a significant amount of work to use it correctly. That's why Next.js was built. But how does Next.js work?
Next.js is a React framework. The difference between libraries and frameworks is important. Libraries are just collections of useful tools. Like with a brick-and-mortar library, you're responsible for finding the specific information and tools you need. You have to call the library and tell it what you need.
In contrast, frameworks handle that for you. When you work within a framework, you don't need to worry about calling the library or pulling the tools. It acts as a frame for your application, giving it a fundamental structure and preventing errors from creeping in.
That's what Next.js does for React. The Next.js framework structures the React library and gives it a solid form. When you start a project using Next.js, the framework configures many settings behind the scenes and provides extra commands that allow you to accomplish tasks that aren't possible through the React library alone. Because of that, building applications within the Next.js framework takes less time while still offering all the benefits of the React library.
## **What Functionalities Does Next.js Offer?**
Next.js offers a broad range of functionalities. The framework was designed to provide not only structured access to the React library but also extra features. When you choose to use Next.js to build an application, you're guaranteeing that you'll have access to these functionalities.
### **Client-Side Rendering for Interactivity**
One of the most valuable tools Next.js offers is client-side rendering. There are three ways that Next.js can render a user interface: client-side, server-side, or static site generation. Client-side rendering is the best way to make an interactive, responsive UI.
With client-side rendering, the UI is generated on the client's end of the application. The server sends basic HTML to the app along with JavaScript code. That JavaScript code contains the instructions for the app to generate the UI, including more complex HTML, in the moment.
This allows the connection between the client's device and the server to happen quickly. All of the complicated parts of the rendering the UI happen on the client's end. As a result, there's no need to constantly query the server regarding how the UI should change based on the client's actions. The UI is able to react to the client instantly, making interactive elements smoother and less prone to delays.
### **Static Site Generation to Help Automate Your Process**
If interactivity isn't a primary goal of the application, then Next.js also supports static site generation. With this method, the user interface is prerendered by the server. More importantly, the server needs to generate this only once. The HTML is created and then stored in a content delivery network (CDN). Whenever that specific UI is needed, the app pulls the HTML from the CDN and presents it. There's no need for any rendering in the moment for the client or the server.
Prerendering your UI with Next.js's static site generation is a great way to automate certain parts of your process. Static pages may not be the most interactive, but they're quick to load and require no work from your own servers. This method takes some pressure off your servers and allows you to automate routine tasks like displaying loading screens, menus, and other low-interaction pages.
### **Ability to Build Complete Web Applications Quickly**
Part of what makes working in any framework so appealing is the way it can speed up application development. When you work with Next.js, you don't need to build your app from scratch. The framework has already laid the foundation and set the parameters for you. It even has rules and guidelines in place to help you avoid making mistakes that could cause delays or failures.
That functionality makes it easy to build your next web application quickly. Next.js helps you avoid wasting time on basic tasks and setup. Instead, you can start working on the meat of your application right away, building a complete, functional, good-looking app in less time.
## **The Impact Next.js Has on the User Experience**
It's clear that Next.js offers developers many potential tools to make applications faster and more efficient. However, the framework also impacts the user experience (UX). Next.js provides flexibility and customization options that make the UX better in three important ways:
- Security
- Speed
- Personalization
Here's how the Next.js framework supports each of these UX elements.
### **Lack of Direct Database Connection, Keeping Static Websites Secure**
Application security is a fundamental necessity for modern developers. If you don't create a secure app, your users are at risk of having their devices hacked and their information stolen. Obviously, this has a significant negative impact on the user experience.
Next.js can help make your apps more secure, particularly if you use static site generation. With static generation, there's no direct connection to any databases. User devices query the CDN instead, which provides the prerendered code. As a result, there's no easy way for hackers to inject malicious code into the database results. Users face a lower risk of malware because Next.js has stripped the need to render code on either end of the process.
Furthermore, static site generation protects user information on your servers, too. Hackers who access your web application won't be able to study its direct connection to your servers because there isn't one. There's no way for them to learn how to call your server databases and potentially access sensitive information like sign-in details or payment information.
### **Significantly Faster Page Load Times**
Whether you choose static site generation or client-side rendering, Next.js can help you significantly reduce page load times.[ According to Google](https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/page-load-time-statistics), visitors are 32% more likely to leave a webpage that takes three seconds to load compared to a page that loads in one second. Reducing page load times is a simple but valuable way to keep users engaged with your site and prevent bounces.
Static site generation means that there's no need to render a page at all. Next.js allows the next page to load significantly faster because all it needs is the HTML that the CDN provides. There's no additional rendering requirement on either end.
Client-side rendering can be almost as fast. There's no extra delay between your server and the client's device, since your server is just providing HTML and JavaScript instructions. The client's device is responsible for rendering the actual user interface. As long as the device has reasonable rendering times, the user will see the entire page significantly faster than other methods allow.
### **Ability to Create a Completely Customized Front End**
After security and speed, the third element of a great user experience is a beautiful, functional user interface. Next.js gives UX teams the ability to build a completely customized front end to fit the app's brand and target audience.
Some frameworks limit what developers can do with various elements. That's the nature of a framework: While it offers support, it also imposes limitations, just like walls in a house. However, Next.js has been carefully constructed to give developers complete freedom to customize the front end of their web applications.
That freedom means it's easy to develop appealing front-end UIs that users enjoy interacting with. There are no clunky requirements that may get in the way of your dev team's goals or needs. You can focus on providing a great experience for your users instead of fighting with the framework or reinventing the wheel.
## **Why Front-End Developers Use Next.js**
You might still be wondering, "Why use Next.js?" It might help to understand its appeal to front-end developers. Devs using the framework appreciate it for the following functionalities.
### **Server-Side Rendering**
Server-side rendering allows your web application to quickly display interactive pages that may not be easy to render on client devices. This tool lets you implement more complicated user interfaces by placing the load on your servers instead of the client's device.
Your server will generate the HTML for each request, along with JavaScript instructions for interactivity. The HTML will allow the page to quickly display a noninteractive page. After that's displayed, the JavaScript instructions will be interpreted behind the scenes to make the page interactive. In most cases, users won't notice the delay between the page appearing and the JavaScript making it functional, since they need time to decide what to click next. Meanwhile, you get to develop more complex interactive pages without risking slowing down your site.
### **Automatic Compilation and Bundling**
A significant benefit of using a good framework like Next.js is the way it takes basic tasks off your plate. Next.js is structured to provide automatic compilation and bundling, meaning that it's "zero config." You don't need to do any configuration to get the framework ready for production.
Without the need to configure anything, Next.js is perfectly optimized for production from the moment you start development. That can save you significant time and prevent annoying and wasteful compilation failures. When your application is finished, all you need to do is test the compilation and bundling process once, and then move it to production. You can trust Next.js to handle the rest.
### **Importing CSS Files**
Next.js allows you to directly import CSS files from a JavaScript file. The built-in CSS parser makes it easy to import global style sheets that will apply to the entire web application. The style sheet will ensure that every part of your app is presented consistently, so you don't need to set the presentation for each element individually.
If you do have specific components that need unique CSS, that's possible too. You can import CSS Module files anywhere in an application just as easily as you would apply a global style sheet. The module will override the global style sheet in the locations you apply it to, so you can customize specific elements with ease.
This is possible because Next.js extends the import function to cover more than just JavaScript. If you choose to use the framework, this extended import functionality makes rapid development simpler and more accessible.
### **Data Fetching**
Next.js data fetching includes server-side rendering, client-side rendering, and static page generation. You're not limited to just one of these methods, either. While you can develop your entire application with one data-fetching technique, you can also combine them so each page of your site is generated as efficiently as possible.
For instance, you could use static generation to automate your simplest pages, such as news articles or blog posts. Meanwhile, you could use server-side generation to load your homepage, where things may frequently change but speed is of the essence. Finally, if you have a ticker page or other pages that should update without a refresh, client-side rendering is ideal. Next.js allows you to choose which pages are loaded with which method, giving you more flexibility.
### **Code Splitting**
Web applications rely on code splitting to function. Most web applications involve multiple pages, each of which can be visited through a specific URL. That makes every page a unique entry point to the app.
Code splitting is the process of dividing the total application's code bundle into chunks that are relevant to each page in particular. This speeds up load times by avoiding the need to render code that's irrelevant to the specific page.
Next.js automatically handles code splitting for you. The framework takes each file in the "pages/" directory and generates a specific JavaScript bundle for it, which will be called up when visitors access the page. This saves you time and effort.
### **React Ecosystem Access**
Finally, Next.js gives you access to the entire React ecosystem. As a React framework, it's built to cooperate with other React components. You can use all of the features the React library offers, taking advantage of a broad range of tools to make your UI more appealing.
## **When Should You Use Next.js for Development?**
If you're still not sure about whether Next.js is right for your application, it might help to understand the situations in which the framework really shines. Some of the best opportunities to use Next.js include the following.
### **Building SaaS Products**
If you have a software-as-a-service (SaaS) product that you want to expand, time is of the essence. Both development time and page load times are essential factors when you're trying to make your SaaS product more appealing. Next.js helps you trim the time wasted on both of these issues.
You can use Next.js to build out new SaaS features and products in less time. The framework will help you move from idea to finished product without having to waste time on configuration and bundling. Meanwhile, the data -fetching options allow you to build an application that loads faster on every page.
### **Building Web Applications and Portals**
Similarly, Next.js is a great way to build new web applications and portals. Paired with the right [Next.js authentication solution](/nextjs-authentication), the static site generation feature helps you build fast-loading pages that allow your users to quickly sign into the app or portal. You can even implement [multifactor authentication](/blog/nextjs-supabase-todos-with-multifactor-authentication) in your portal to strengthen your security and protect your users' data.
### **Creating an Interactive User Experience**
Next.js is structured to make interactivity a priority for the user interface. Whether you use server-side or client-side rendering, you can produce highly interactive webpages that load in less time. Each page can be built with the rendering method that allows for the most efficient interaction.
Furthermore, the ability to customize your front end makes Next.js a valuable tool for developing a unique UI that's interactive in the ways you need. You're not stuck trying to build an application around the framework's assumptions. The result is a front-end UX that's ideal for any interactive application.
## **How You Can Incorporate Next.js Into Your Development Environment**
If you're interested in using Next.js in your development environment, Clerk can help. [Clerk offers the easiest solution for Next.js authentication](/nextjs-authentication) on the market. Learn more about how you can keep your Next.js application secure and accelerate your development with Clerk's Next.js authentication tool today.
---
# Authentication vs. Authorization: What's the Difference?
URL: https://clerk.com/blog/authentication-vs-authorization.md
Date: 2022-07-06
Category: Insights
Description: Understand the differences between authentication vs. authorization and the purpose they both serve.
Authentication and authorization are essential parts of security. Companies need both to protect their networks and systems from unauthorized access to business resources. Let’s look at the core elements of authentication vs. authorization and ways to leverage them to enhance your organization’s security posture. The evolution of network security makes access control more critical than ever. While people tend to use the terms *authentication* and *authorization* interchangeably, it’s important to understand how they contrast and how each helps protect company applications.
## **The Differences Between Authentication vs. Authorization Explained**
Below is an overview of the differences in how each process works.
### **The Authentication Process**
[Authentication](/features/web3) focuses on recognizing and proving that an individual is using the correct identity. For example, when someone logs into their workstation, they’re prompted for verification through credentials like a username or password.
An authentication solution running behind the scenes checks the information provided against a database of stored credentials. If the data checks out, the user gains access to the target resource.
Usernames and passwords have been the go-to for most businesses when asking workers to verify their identity. Security protocols typically require employees to keep their passwords secret to prevent unauthorized users from using their credentials in a way that could harm the company.
As hackers have evolved the methods they use to go after companies’ systems, passwords have become more vulnerable. Many IT departments try to keep passwords secure by requiring users to enact a certain degree of complexity when creating them. In addition, workers are prompted by the system to change their passwords frequently, usually every 30 days.
The onus is on IT personnel to manage stored complex passwords. The difficulty of remembering intricate passwords often leads users to reuse their passwords on multiple devices and in different systems. Even if a password meets the length requirements, the actual entry phrase may be extremely uncomplicated, making it easy for cybercriminals to guess the pattern and gain system access using stolen credentials.
### **The Authorization Process**
Authorization covers the permissions provided to users when it comes to system resources. For example, someone working in the accounting department may have permission to access accounting software that isn’t granted to someone who works in operations.
However, having permission to access that application doesn’t mean the user has free rein to go where they want. While they may have permission to log certain transactions, the worker may be blocked from functions that allow them to retrieve sensitive information like Social Security numbers and bank account information.
Additional privileges are typically granted based on a user’s role within a company. For example, an IT director would likely have system permissions that aren’t given to an application developer. At the same time, that IT director would likely not have access to the repository where software engineers store their code.
System administrators usually control who receives privileges to access various organizational resources and how far those permissions extend. Authorization is about making sure individuals receive the permissions they need and ensuring they don’t proceed beyond those set boundaries.
Let’s use a nightclub analogy to wrap up the contrast between authentication and authorization. Authentication is what gets you past the line and through the doors. However, that doesn’t mean you get to go right up to the VIP lounge. Instead, someone must give you specific permission to access that area.
## **Types of Authentication**
Let’s look at the different methods employed by businesses to validate a user's identity.
### **Multifactor Authentication**
Passwords don’t offer the level of security that’s necessary in today’s digital world. Cyberthieves use methods like keyloggers to capture password entries or look for clues to a person’s work credentials by poring over their social media profile. Some resort to using password-cracking tools, which try out various username-and-password combinations until they get a hit.
[Multifactor authentication](/features/multifactor-authentication) (MFA) adds an extra layer of security to identify users. That way, hackers need more than a user’s password to get past a company’s security. Users must identify themselves in multiple ways, reducing the risk of hackers using employee information to steal data or sabotage business systems.
### **Two-Factor Authentication**
Two-factor authentication (2FA) requires users to provide two authentication factors before receiving access to a system, application, or device. It provides more robust security protections than requiring only a password or code.
Most 2FA methods require users to provide a password and then a security token or one-time password (OTP) that is generated from a separate device, like a mobile phone. The extra layer of security makes it more difficult for attackers to use a password to access a user’s device or get into their online accounts.
### **Single-Factor Authentication**
Single-factor authentication (SFA) grants access to a system by asking a user for only one type of identification. Password-based SFA is the most common type used by organizations. The best way to implement SFA is by establishing robust password protocols that are enforced by system administrators.
The drawback to SFA is that many users have difficulty coming up with strong passwords that they can easily remember. Problems also result when IT departments don’t enforce standards that ensure users don’t try to get around the protocols by repeating passwords or using patterns that are easy for an experienced hacker to figure out.
### **Token Authentication**
Tokens are a form of 2FA that uses digitally encoded signatures to authenticate a user attempting to access a network or another IT resource. The token comes in the form of a unique OTP that's generated every time a user logs into a system. Users enter the information along with another authentication factor to prove their identity.
Many organizations use security tokens because it’s easy to scale the system to accommodate new employees. It’s also possible to use access tokens on multiple servers. The flexibility of the process allows companies to use security tokens for various applications and websites simultaneously.
**Biometric Authentication**
Biometric authentication uses distinct biological characteristics to verify someone’s identity. Using your fingerprint to log into your phone is a form of biometric authentication. The physical trait used to identify a person must match information that was previously stored in a biometric authentication system.
Other standard biological information used for this method of authentication include:
- Genetic material, like DNA
- Iris recognition
- Retinal scans that analyze the blood vessels at the back of the eyes
- Hand geometry recognition, which evaluates the unique characteristics of a person’s hand
- Voice identification
Biometric devices consist of a scanner, technology that converts and evaluates biometric data for comparison, and a database that stores biometric information. The device used for scanning can include a fingerprint reader or voice analyzer. Once the user provides their data, the biometric application attempts to match it to a previously stored sample.
## **How to Choose an Authentication Strategy**
Most modern companies have developers located everywhere, making it more complicated to implement effective security measures. Establishing an authentication strategy goes a long way toward striking a balance between continued flexibility for employees and protecting business assets.
### **Evaluate Your Environment**
Look at your company's available hardware to determine whether it’s sufficient to support multiple login and authentication requests. You don’t want to end up with a bunch of authentication failures that keep workers from performing their jobs. Review the network connectivity available and make sure remote users have what they need to establish connections.
### **Establish a Strong Password Policy**
If passwords are going to be part of your security posture, you need to establish strong policies governing their use. First, encrypt any passwords that are sent over the network to prevent them from getting intercepted. You want to make it difficult for attackers to crack user credentials. Ideally, the password should change by the time the attacker figures things out.
Passwords should be easily remembered by individual users but complex enough to ward off potential hackers. While characters like hashtags and “at” symbols can aid in that effort, adding too many of them can make it harder for users to remember. Users can add a unique suffix to a password, like [dandelion@hardtoguess.net](mailto:dandelion@hardtoguess.net), to make it more complicated. Other rules your organization should follow when it comes to password creation include:
- Not using any part of the user’s name
- Making the password at least eight characters in length
- Having the password contain at least one non alphabetic character
- Adding both upper- and lower-case characters
- Prompting users to change passwords at least every 45 days, though 30 is ideal
Make sure to limit how many times users can try logging in with an incorrect password before a lockout policy is implemented. Many hackers use tools that endlessly guess at password options. However, be aware that hackers can take advantage of such a policy to launch a denial-of-service (DoS) attack that locks out legitimate users. If employees forget their password, set up options that allow them to recover their account securely.
### **Consider Multifactor Authentication**
Adding MFA to your organization’s security posture provides extra layers of protection around employees' credentials and sensitive data. If you work in certain industries, like finance, MFA may be required to comply with established regulations.
The noninvasive nature of MFA doesn’t interfere with your IT infrastructure. Many MFA solutions on the market allow companies to enable single sign-on (SSO) for all company platforms, meaning users don’t have to keep up with complicated passwords for every application.
MFA offers additional security for remote workers, whom hackers often target. Requiring a second confirmation of identity alleviates concerns around cyberthieves using compromised credentials to log into company devices or systems.
## **Types of Authorization**
Organizations should establish access boundaries for users, software applications, and even specific hardware using company resources. The two main methods of granting authorization to users are role-based access control (RBAC) and attribute-based access control (ABAC).
### **RBAC**
RBAC helps organizations maintain control over authenticating users while authorizing them to access systems and applications. It focuses on providing rights to individuals based on their role, the environment in which they work, and specific resource attributes. RBAC controls broad access granted to users throughout an organization.
Administrators manage the distribution of permissions to various organizational roles and the users assigned to those groups. Certain users may be assigned to a group that lets them edit sensitive information while individuals in a different category receive view-only permission.
Some users may be eligible for assignment to multiple role groups that expand their access within an organization. A project manager may have more permissions granted to them via several groups while an analyst working under them would receive more limited access.
The most significant benefit of using RBAC for authorization is that administrators don’t have to make major changes whenever someone switches jobs or leaves the company. Instead, the administrator removes that individual from a role group and moves them to a new one. RBAC also makes it easier to grant necessary permissions to new employees based on their roles.
### **ABAC**
ABAC, also called policy-based access control (PBAC), is often put in place to protect information held in databases, business applications, application programming interfaces, and microservices contained within complicated architectures. Users receive permission to access system resources based on attributes like their role, the device being used, the attempted action, or their location. Each ABAC attribute must align with an established policy before the user receives access to the desired resource.
Organizations typically use ABAC when there’s a need to set up more dynamic security parameters versus those available through RBAC. The granular detail makes it possible for businesses to meet unique security challenges.
Policies for ABAC fall under the governance of corporate policies. Any changes made are enforced throughout the entire company. It’s also easier to implement complicated regulatory requirements with ABAC. Administrators gain real-time control over users' attempts to access company assets, systems, and networks.
ABAC makes it possible to manage a larger pool of control factors versus RBAC. It reduces the risk of users managing to gain unauthorized access thanks to the level of control it offers. For example, someone who works in finance could be restricted from accessing certain bank information outside of specific time periods or particular locations.
## **Authorization and Its Relation to User Permissions**
Authentication is about establishing the identity of an entity trying to gain access to assets, networks, systems, or data controlled by an organization. That includes verifying the host ID of a remote machine, validating the certificate of a software component, or checking an employee's credentials through various means.
Once that entity gains access, the authorization process kicks in to determine what permissions are available. That includes looking at the role groups that entity belongs to and what access they have in different systems and applications.
## **How Authorization and Authentication Relate to Identity and Access Management**
Identity management involves making sure that users have the access they need for various IT resources. It ties directly into the process of authenticating users and access management, controlling where users are allowed to go and what actions they can take with granted permissions.
One benefit of identity and access management is that organizations can ensure that users don’t have more access than necessary. That helps thwart attackers hoping to use stolen credentials to access company data and networks.
## **How to Determine Which Method of Authentication Is for You**
Network security aims to ensure authorized individuals have required access while keeping out unauthorized users. Setting up ABAC properly can quickly devolve into complexity. If there are no strict regulatory guidelines for your industry, then RBAC may be sufficient for your organizational needs. There are also additional costs and human resources required to implement ABAC.
Regardless of which method you choose, try to apply the minimum number of filters that are necessary to comply with your company's security posture. Plan out directory data and the approaches your business wishes to take in granting access.
It’s also possible to use RBAC and ABAC in a hierarchical manner, through which RBAC covers broader protocols and ABAC kicks in when there’s a need for finite security management. An example of that would be using RBAC to figure out which groups within an organization are allowed to access a resource. The company could then use ABAC to figure out the permissions given to users and any actions they can take.
## **How You Can Utilize Authentication Concepts and Authorization Methods**
Authorization policies manage access to IT resources and control what users do with that permission. If you are going to make passwords part of your company’s access protocols, make sure you implement strong password policies to prevent employees from using combinations that could make it easy to compromise their credentials.
One way for companies to expand their security protections is by implementing MFA in addition to using IDs and passwords. Having a secondary method for user authentication keeps hackers from using stolen information to access company resources.
When deciding between RBAC and ABAC, go with the option that covers your essential security needs without adding unnecessary complexity. You can also choose to combine the two to ensure that you’ve established the most robust security protection possible for your organization.
Ready to start your authentication journey? [Start building your authentication journey for free with Clerk](https://dashboard.clerk.com/sign-up).
---
# The New Wave Stack
URL: https://clerk.com/blog/new-wave-stack.md
Date: 2022-06-02
Category: Insights
Description: A custom Remix stack with Clerk, Fauna, and Netlify.
### Introduction
In March 2022, Remix introduced a feature of the Remix CLI called [Remix Stacks](https://remix.run/docs/en/v1/pages/stacks). This allows you to quickly and easily generate a Remix project from a pre-created template. These custom stacks are named after music genres. At Clerk, we’re all about making the developer experience as easy as possible, so we knew this was a perfect opportunity to combine the best of Remix’s development tools with Clerk’s easy-to-use user management and authentication platform.
New wave music was defined by the transition from the punk music scene to a more radio-friendly form of pop expressionism. In many ways, Modern Web tools like Clerk, Netlify, and Fauna represent much of the same thing for building web applications. Clerk’s custom Remix stack takes the DIY (Punk) freedom of designing an app the way you want and combines it with production-ready (Pop) resources to make your product accessible to a broader audience.
Welcome to The New Wave Stack. Let’s get happy.
[Check out the official New Wave Stack repo on GitHub](https://github.com/charles-clerk-dev/new-wave-stack)
The critical parts of any [custom Remix stack](https://remix.run/docs/en/v1/pages/stacks) are:
- Automatic deployment - Netlify
- Authentication - Clerk
- Database - Fauna
- Testing - Cypress, RTL, Jest
- Linting/Formatting/TypeScript - ESLint, Prettier
### Deployment with Netlify
While it may seem odd to start with deployment, it can often be much more challenging to configure later on in the development process. If you can get deployment set up early and test deployment often, it can save you an incredible amount of stress in the future.
This stack is all about making things easy for developers, so Netlify was an obvious choice for deployment. Netlify allows you to connect a git repository and set up deployments to happen when a branch is merged into production. Or, if you prefer to deploy manually, Netlify has an easy-to-use CLI. It also provides deployment previews, rollbacks to previous deployments, and many other great features that make getting your application in front of users incredibly simple.
### Authentication with Clerk
The New Wave Stack comes with Clerk’s complete authentication and user management features. This means that developers don’t have to worry about building many of the things users have come to expect from web applications. Components like Sign In, Sign Up, and User Profiles are available from the ground up. Clerk’s wide variety of authentication options will allow you the flexibility to manage your users the way you want. Setting up an account on Clerk takes seconds, and configuring your New Wave app is as simple as adding your API keys.
### Database management with Fauna
> \[!WARNING]
> Fauna’s service [ended on May 30, 2025](https://web.archive.org/web/20250319171743/https://fauna.com/blog/the-future-of-fauna), but they’ve [open-sourced their codebase](https://faunadb.org).
Fauna is an excellent cloud-based database solution that combines the flexibility of NoSQL systems with the relational querying capabilities of SQL databases into a transactional database with GraphQL support and other modern features, such as real-time streaming.
Although Fauna offers built-in identity, authentication, and password management functionality, it requires that you manage the user data yourself. Clerk provides features like social SSO, passwordless authentication, multi-session management, and more without the hassle of managing your user and identity service. Clerk’s JSON Web Token (JWT) Templates feature makes it easy to authenticate queries to your Fauna database.
We have [a comprehensive walkthrough](/tutorials/build-movie-emoji-quiz-with-remix-fauna-and-clerk#set-up-fauna-database) on building an application with Remix, Clerk, and Fauna. Working through this tutorial will give you a solid understanding of how to set up your first Fauna database and how to query the database from your Remix application. It’s also quite a lot of fun.
### Styling with Tailwind
Like everything else in this stack, our approach to styling is to provide the tool that allows you to build your application quickly and efficiently, which is why we configured The New Wave Stack to use Tailwind out of the box. Tailwind is possibly the most common solution for developers styling their Remix applications, and there are plenty of good reasons why. It allows for inline styling, which can speed up development time, and the generated CSS file for even large applications is usually less than 10kb.
### Testing with Cypress/Testing Library
Developer experience is always a primary focus for Clerk, so we chose to configure this stack with Cypress for end-to-end testing. Cypress is commonly used in Remix stacks as it provides an effortless and straightforward testing environment. We’re sticking with the classic Testing Library/Jest combo for lower-level tests.
### Formatting
Finally, we arrive at the last few touches that make your code sparkle. We’ve set up Prettier for formatting, ESLint to take care of linting, and TypeScript to manage typing.
### Conclusion
It was a lot of fun building out the New Wave Stack and discovering how each piece seemed to fit naturally with the others. One of the benefits of Modern Web tools is the intuitive way they can be made to work together. It’s getting faster and easier for talented developers to take an idea and immediately begin putting it together. We want people to spend as little time as possible on setting up their app so that they can focus their effort on what makes their project special and unique.
---
# The future of authentication is both stateful and stateless
URL: https://clerk.com/blog/future-of-auth-stateless-and-stateful.md
Date: 2022-04-28
Category: Insights
Description: Stateful authentication is more secure. Stateless authentication is faster. A hybrid approach delivers the best of both worlds.
Should session authentication be stateless or stateful? This simple question has been the source of many spirited debates, especially on Hacker News where it's [spurred](https://news.ycombinator.com/item?id=21783303) [many](https://news.ycombinator.com/item?id=18353874) [lively](https://news.ycombinator.com/item?id=16517412) [threads](https://news.ycombinator.com/item?id=18804875) over the years.
The discussion always boils down to two primary points:
1. Stateful authentication is more secure
2. Stateless authentication is faster
In this post, we'll first discuss the reasons behind both, and explain how a hybrid approach offers the best of both worlds.
## What is stateless? What is stateful?
This post will be hard to follow if you don't know the difference between stateful and stateless authentication, so let's start from there.
### Stateful authentication
Stateful authentication relies on a database (or another mechanism for storing "state") to determine if a session is still active.
When a session begins, a unique identifier is created to be passed along with future web requests.
When requests are received, that unique identifier is used to query the database and check if the session is still active.
### Stateless authentication
Stateless authentication relies on cryptography to determine if a session is still active.
When a session begins, a cryptographically signed token is generated (usually in the form of a JWT) that encodes the user's ID and the timestamp when the session expires. This token is then passed along with future web requests.
When requests are received, the backend confirms that the token's signature is valid and that it has not expired. This is considered stateless because no database is involved, just cryptography to verify the signature.
## Stateful authentication is more secure
The first issue to consider is security. Love it or hate it, security is the most important feature on any authentication system.
Stateful authentication is considered more secure because the database can be updated at any time to mark the session as inactive. When the next request is received, the backend will notice the change and refuse the request.
Since the database is checked on every request, instantaneous session revocation is possible. This is ideal if an attacker has access to a system and needs to be stopped immediately.
With stateless authentication, though, the backend only inspects the token. No database is involved, so the token will remain valid until the hardcoded expiration is passed. So, if an attacker gets hold of a token, their attack can continue until the expiration passes.
## Stateless authentication is faster
Since stateful authentication is more secure, you might expect it's the easy choice. It's not, because stateless authentication is *significantly* faster.
The cryptography required for stateless authentication can consistently be performed in under 1 millisecond.
On the other hand, the database query required for stateful authentication can take 10-20 milliseconds.
Authentication happens on every request, so the performance hit of a stateful approach quickly starts to look like a common bottleneck. As a result, developers start looking for faster alternatives, and naturally gravitate toward stateless authentication.
## Hybrid stateful and stateless authentication offers the best of both worlds
Fortunately, authentication is not a zero-sum game. Developers can build a hybrid approach of stateful *and* stateless authentication that is both fast and secure.
The magic comes from a simple sleight-of-hand: instead of setting stateless tokens to expire with the session, they can be set with a short expiration and refreshed periodically.
When a token is refreshed, the database is checked to ensure the session is still active. As a result, sessions can still be revoked before they end. The potential delay before revocation completes depends on how frequently tokens must be refreshed. If a 60 second expiration is assigned to each token, then revocation will take a maximum of 60 seconds.
Refreshing stateless tokens is a stateful process, since it requires querying the database to confirm the session is still active. But with the optimal approach, refreshes will happen asynchronously, except for the very first load after an application is closed.
### In practice
Clerk changed to a hybrid approach for session management 6 months ago. The functionality is built-in to our SDKs without any configuration, so most developers don't even recognize it's happening.
Our stateless authentication tokens are set to expire every 60 seconds. In practice, here's how it works:
1. When a user signs in, a stateless authentication token is created immediately.
2. An asynchronous poller is started on the frontend to refresh the stateless token every 50 seconds. The 10 second difference is to account for potential network delays and clock-skew between our token generator and the developer's backend.
3. While the user is active on the application, every request to the developer's backend will include an active, stateless authentication token.
But now, let's say the user closes the application for a few minutes so our poller stops. When the user revisits the application, the latest token has already expired since 60 seconds have elapsed.
In this case, we need to update the token synchronously before requests to the backend can be processed. It's the one exception to an otherwise completely stateless authentication experience.
In the end, Clerk's authentication solution is both stateful and stateless. Sessions can be revoked within 60 seconds, yet the vast majority of requests use stateless authentication and can be verified in under 1ms.
## Conclusion
To address speed and security concerns, we believe the future of authentication is both stateful and stateless. We've been using this solution for over 6 months and it has proven to be robust and resilient over many millions of refreshes and authentications.
Our [session management](/features/session-management) is included free in every Clerk plan - give it a try to test for yourself, or watch your network tab while signed in on [clerk.dev](/) to see it in action!
---
# 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:
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\*:**
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
- `` 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:
## 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!*
---
# 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
```
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 [``](/components/sign-up) and [``](/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:
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:
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.