Auth System

When developers are building out projects and it comes done to adding authentication & authorizations to a project, everybody is telling you to not roll your own auth system. “It’ too complicated, too many features and it takes out too much time from the actual project itself”.

I can partly agree with that statement, because there is a lot of features that needs to be built within an auth system. Signup, login & logout, email verification, password recovery, 2FA, etc. That is a lot of features that needs to be built, if you want a full auth system. But I also think it’s good to learn how authentication and authorization works, then just picking a prebuilt solution, or an external provider. In my case is it to build a simplified version of the system, to deeply understand how authentication & authorization works, and what goes into building a simplified version of it.

Requirements 📋

In this project, I only choose to focus on four aspects of the system, to have simple MVP to go out from.

1. Signup
2. Login
3. Logout
4. Authorization / Secure API endpoint.

I think these four aspects is needed in almost all systems which requires some sort of authentication/authorization, the other functionalities like password recovery & email verification is really not needed if you only want to build out an admin panel for example.

The purpose 🧠

The purpose of building out this project, was to learn about how JWTs (tokens) could be utilized to build an authentication system, as well as be used to have a decentralized authorization system. I also wanted to learn how to manage & store user passwords securely in a database. Learning about how the refreshing flow of the access- & refresh-token was done, was also one of the primary focuses behind building this project.

The solution 🛠️

The outcome of this project was a very simple web application alongside an API & database to store and query the user data. The solution contains three pages for signing up and logging in the user, as well as a home page for the user to be able to see their information/data.

Technologies 🪛

The web app was built using Vite’s React + TypeScript template/boilerplate to get a good foundation to build the web app on top of. I choose to use the Shadcn UI component library, to easily get a nice and functional UI up and running. I utilized a lot of the prebuilt form components for the signup and login page. These components also has a strong API to handle API errors alongside user input validation.

For the data fetching/state management library I choose to use TanStack’s React Query, which is a strong battle-tested library used to fetch and manage data from an API. For the data/schema validation, I choose to go with Zod, which compliments both React Query, but also the Shadcn UI components a lot, by helping out with the data validation coming from the API.

For the API framework, I choose to go with Fastify, because it’a a simple and fast API framework, which allows you to build a simple API fast, and has a rich ecosystem of different plugins. One of these plugins I used was the “fastify-zod-type-provider”, which translates Zod schemas into the validation JSON structure Fastify needs, as well as OpenAPI JSON structure, so we get rich API documentation.

Pages 📄

For this project, I choose to keep the web app routes very simple, the web app really only needed 3 pages:

• Signup (allow users to sign up)
• Login (users can login)
• Home page (show user’s information)

A very simple design as made, so the only content that was on these pages was only the most necessary information. The focus of this project, wasn’t so much about the UI and user experience, but more what actually goes on behind the scene with the API and authentication/authorization of the user on the web app. Below can you see an example of the 3 different pages, and how they look.

API Structure 🧱

I tried to structure the API as simple as possible, because I wanted the whole system to be as simple as possible. So only the most necessary endpoints and database queries is made.

I grouped the endpoints into two categories:

• Auth
  • These endpoints are so called “actions”, which consists of mostly POST endpoints. These are the endpoints you would call to signup, login, logout and refresh the access token
• Users
  • Endpoints under the users path are used to GET information about the logged in user. In this project we only have one endpoint to receive the logged in user's details.

With this approach, we group the necessary endpoints together, which are related to auth (authentication), and the endpoints which are related user data together. This ensures that we follow the resource endpoint pattern, which is mostly used in RESTful APIs.