Custom Authentication: The Good, the Bad, and the Ugly

Custom authentication

Let’s make this clear from the outset: when possible, we should avoid implementing custom authentication strategies. There are several great providers (including Auth0, Firebase, AWS Cognito, and Magic.link, just to name a few) that are putting a lot of effort into making authentication secure, reliable, and optimized for many different situations.

When investigating authentication strategies for a web app, we highly recommend looking into a well-established service provider because this is possibly one of the most critical aspects of a dynamic web application.

In this lesson, we’re looking into creating a custom authentication mechanism for a simple reason: we just want to understand at a high level how authentication works, how to make it as secure as possible, and what the critical factors of a custom auth system are.

As we’ll find out during this lesson, there will be several limitations when implementing custom authentication mechanisms. For instance, we highly discourage implementing client-side authentication on statically generated websites because it forces us to authenticate users on the client side exclusively, possibly exposing sensitive data to the network.

For that reason, we’ll create a new Next.js web application that will use the API routes for communicating with a data source (typically a database) and retrieving the user data.

Write a login API

We can start writing the login API. Please keep in mind that the following code is not meant to go to production; we’re just taking a simplified, high-level overview of how authentication works.

Let’s start by creating a /pages/api/login.js file by exporting the following function: