DEV Community: t sriya

Part 5 : Building an Authentication System from Scratch

t sriya — Thu, 02 Jul 2026 17:14:31 +0000

Logout, Deployment & Lessons Learned

Over the previous articles, we built a complete authentication system from scratch.

We implemented:

Backend architecture using a layered design.
User registration with secure password hashing using bcrypt.
Login using JWT Access Tokens and Refresh Tokens.
Protected routes and authentication middleware.
Forgot Password and Reset Password workflows using Resend for email delivery.

At this stage, the authentication system is fully functional. However, one important piece is still missing—logging the user out securely.

In this final part, we'll implement the logout flow, deploy the application to production, discuss the challenges encountered during deployment, and summarize the key learnings from the entire project.

Why Logout Matters

Logging out isn't just about redirecting the user back to the login page.

In applications that use JWT authentication, the client may still possess valid authentication tokens. If those tokens remain active after logout, they could potentially be reused until they expire.

A secure logout process ensures that the user's session is completely terminated and prevents the generation of new access tokens.

Logout Flow

The logout process is shown below.

User clicks Logout
        │
        ▼
Frontend sends Logout Request
        │
        ▼
Backend authenticates User
        │
        ▼
Invalidate Refresh Token
        │
        ▼
Return Success Response
        │
        ▼
Frontend clears Authentication State
        │
        ▼
Redirect to Login

Unlike login, logout does not require the user to provide credentials. Instead, the request is authenticated using the existing access token.

Backend Logout Implementation

The logout request first passes through the authentication middleware, which verifies the access token and identifies the currently logged-in user.

Once the user is authenticated, the backend removes the stored refresh token from the database.

By invalidating the refresh token, the application prevents future access token generation, even if the old access token has not yet expired.

const logout = async (req, res) => {
  try {
    const userId = req.user.id;
    const result = await authService.logout(userId);
    return res.status(200).json(result);
  } catch (err) {
    return res.status(400).json({
      success: false,
      message: err.message,
    });
  }
};

Repository

The repository performs the database operation required for logout.

Its responsibility is simply to clear the refresh token stored against the authenticated user.

const updatePassword = async (password_hash, id) => {
  await pool.query(
    `UPDATE users SET reset_token= $1, reset_token_expiry =$2, password_hash =$3 where id= $4`,
    [null, null, password_hash, id]
  );
};

Keeping this logic inside the repository maintains the same clean architecture used throughout the project.

Frontend Logout

After receiving a successful response from the backend, the frontend clears all authentication-related data.

This includes:

Access Token
Refresh Token
User Information
Authentication State in Redux

Once the application state is cleared, the user is redirected to the login page.

This ensures that protected routes are no longer accessible.

Deploying the Application

With all authentication features complete, the next step was deploying the application.

I chose the following platforms:

Application	Platform
Frontend	Vercel
Backend	Render
Database	PostgreSQL

This setup closely resembles how many real-world applications are deployed.

Backend Deployment (Render)

The backend was deployed to Render.

Deployment required configuring several environment variables, including:

Database credentials
JWT secrets
Resend API key
Frontend URL

One important lesson I learned is that environment variables are never deployed automatically from the local .env file.

They must be manually added through the Render dashboard.

Frontend Deployment (Vercel)

The React application was deployed using Vercel.

Since this is a Single Page Application (SPA), client-side routing required additional configuration.

Without proper routing configuration, directly visiting URLs such as:

/auth/reset-password/:token

resulted in:

404 NOT FOUND

Configuring Vercel to redirect all requests to index.html resolved the issue and allowed React Router to handle client-side navigation correctly.

Challenges I Faced

Building the authentication system was only part of the journey. Deploying it introduced several real-world challenges.

Some of the issues I encountered included:

SMTP Connection Errors

Initially, I used Nodemailer with Gmail SMTP.

While it worked perfectly in the local environment, the deployed backend on Render consistently failed with IPv6 connection errors.

After investigating the issue, I migrated to Resend, which provided a much simpler and more reliable solution for transactional emails.

Missing Environment Variables

During deployment, the backend repeatedly failed because required environment variables had not been configured on Render.

Although the application worked locally, production deployments require all secrets to be added manually through the hosting platform.

This reinforced the importance of understanding environment management.

Frontend Routing Issues

Password reset links worked locally but returned 404 errors after deployment.

The issue turned out to be related to Vercel's handling of React Router.

Configuring proper SPA rewrites fixed the problem.

CORS Configuration

Since the frontend and backend were deployed on different domains, proper CORS configuration became essential.

Restricting requests to only trusted frontend origins ensured secure communication between the client and server.

Key Learnings

Building this authentication system taught me much more than implementing login and registration.

Some of the biggest takeaways include:

Designing a scalable backend using layered architecture.
Understanding how password hashing works internally.
Implementing stateless authentication using JWT.
Managing Access Tokens and Refresh Tokens securely.
Building a complete password recovery workflow.
Integrating third-party services like Resend.
Debugging production deployment issues.
Managing environment variables across different platforms.
Deploying a full-stack application to production.

More importantly, I learned that building software isn't just about writing code—it's equally about understanding architecture, security, debugging, deployment, and real-world problem solving.

Final Thoughts

Authentication is one of the foundational building blocks of modern web applications.

While libraries and third-party authentication providers make implementation easier, building the entire authentication flow from scratch provides a much deeper understanding of how these systems work internally.

This project helped me understand not only authentication but also backend architecture, API design, database interactions, deployment strategies, and security best practices.

Although there are many possible enhancements—such as email verification, role-based access control, OAuth login, Redis token blacklisting, and multi-factor authentication—the current implementation already provides a strong, production-ready authentication foundation.

I hope this series helps anyone looking to understand authentication beyond simply copying code from tutorials.

Live App: https://auth-flow-five-iota.vercel.app/auth/
Backend API: https://auth-flow-backend-1v2h.onrender.com/
github url: https://github.com/sriyaT/Auth-Flow

Connect : LinkedIn : https://www.linkedin.com/in/t-sriya-b4234510a/, github : https://github.com/sriyaT

Happy Coding! 🚀

Author: Sriya T.

Part 4 : Building an Authentication System from Scratch

t sriya — Thu, 02 Jul 2026 16:50:08 +0000

Implementing Forgot Password & Reset Password with Resend

In the previous article, we implemented secure user authentication using JWT Access Tokens and Refresh Tokens. Users can now register, log in, and access protected resources.

However, authentication systems must also handle a common real-world scenario—users forgetting their passwords.

Instead of creating a new account, users should be able to securely reset their existing password.

In this article, we'll build a complete password recovery workflow using Resend, secure reset tokens, PostgreSQL, and React.

Why a Password Reset Flow?

Passwords are intentionally stored as one-way hashes using bcrypt, which means they cannot be recovered—not even by the application itself.

Because of this, the only secure solution is to let users create a new password after verifying their identity.

The password reset process should:

Verify that the email belongs to a registered user.
Generate a secure, unique reset token.
Expire the token after a limited time.
Deliver the reset link through email.
Allow password updates only after validating the token.

This approach keeps user accounts secure while providing a smooth recovery experience.

Forgot Password Flow

The complete workflow is shown below.

User clicks "Forgot Password"
          │
          ▼
Enter Registered Email
          │
          ▼
Backend verifies email
          │
          ▼
Generate Secure Reset Token
          │
          ▼
Store Token & Expiry in Database
          │
          ▼
Send Reset Link via Resend
          │
          ▼
User receives Email
          │
          ▼
Clicks Reset Link
          │
          ▼
Reset Password Page
          │
          ▼
Submit New Password
          │
          ▼
Validate Token
          │
          ▼
Hash New Password
          │
          ▼
Update Database

Why I Chose Resend

To deliver password reset emails, I chose Resend instead of configuring a traditional SMTP server.

Although SMTP works perfectly well, it often requires:

SMTP host configuration
Port configuration
App passwords
TLS configuration
Provider-specific settings

Resend provides a much simpler developer experience.

Advantages of Resend

Simple REST API
Excellent Node.js SDK
Reliable email delivery
Clean documentation
Easy integration
No SMTP configuration required

This allowed me to focus on the authentication workflow instead of managing email server configuration.

Generating a Secure Reset Token

Once the backend confirms that the email exists, it generates a unique reset token.

I used:

const resetToken = crypto.randomUUID();

This creates a cryptographically secure UUID that is extremely difficult to guess.

The token is then assigned an expiration time.

const resetTokenExpiry =
new Date(Date.now() + 30 * 60 * 1000);

In this project, the reset link remains valid for 30 minutes.

Storing the Reset Token

Instead of sending the token directly without tracking it, the application stores both:

reset_token
reset_token_expiry

inside PostgreSQL.

Users Table

Email

Password Hash

Reset Token

Reset Token Expiry

These fields are later used to verify whether the reset request is still valid.

Repository Layer

The repository is responsible only for updating the database.

It stores:

reset token
expiration timestamp

for the corresponding user.

const saveRefreshToken = async (userId, refresh_token) => {
  await pool.query(`UPDATE users SET refresh_token= $1 where id = $2`, [
    refresh_token,
    userId,
  ]);
};

Because database logic is isolated inside the repository, the service layer remains focused only on business logic.

Service Layer

The service performs the complete Forgot Password workflow.

It is responsible for:

Finding the user by email.
Generating a secure token.
Setting an expiration time.
Saving both values in PostgreSQL.
Constructing the password reset URL.
Sending the email using Resend.

const forgotPassword = async (userEmail) => {
  const user = await userRepository.findByEmail(userEmail);
  if (!user) {
    throw new Error("user not found!!");
  }
  const resetTokenExpiry = new Date(Date.now() + 30 * 60 * 1000);
  const reset_token = crypto.randomUUID();
  await userRepository.resetPassword(reset_token, resetTokenExpiry, userEmail);
  const resetUrl = `${process.env.FRONTEND_URL}/auth/reset-password/${reset_token}`;
  await emailService.sendEmail({
    from: "onboarding@resend.dev",
    to: userEmail,
    subject: "Reset Your Password",
    text: `Click here to reset your password: ${resetUrl}`,
  });

  return {
    success: true,
    message: "Password reset token generated successfully",
  };
};

Keeping this logic inside the service makes the controller extremely lightweight.

Email Service

Rather than sending emails directly from the authentication service, I created a dedicated Email Service.

This follows the Single Responsibility Principle, making the authentication service responsible only for authentication.

The Email Service handles:

Initializing the Resend client.
Preparing the email.
Sending the email.
Handling delivery errors.

const { Resend } = require("resend");

const resend = new Resend(process.env.RESEND_API_KEY);

const sendEmail = async ({ from, to, subject, text }) => {
  try {
    const response = await resend.emails.send({
      from,
      to,
      subject,
      html: `
        <div style="font-family:sans-serif">
          <p>${text}</p>
        </div>
      `,
    });

    console.log("Resend response:", response);

    return response;
  } catch (err) {
    console.error("Resend Error:");
    console.error(err);
    throw err;
  }
};

module.exports = { sendEmail };

Because the Email Service is reusable, future features such as:

Email Verification
Welcome Emails
Account Notifications

can all use the same implementation.

Sending the Reset Link

After generating the reset token, the backend creates a URL pointing to the frontend.

https://your-app.com/auth/reset-password/<token>

The user receives an email similar to:

Reset Your Password

Click the link below to reset your password.

https://your-app.com/auth/reset-password/<token>

Reset Password Flow

Clicking the email redirects the user to the Reset Password page.

The frontend extracts the token from the URL.

/auth/reset-password/:token

The user enters:

New Password
Confirm Password

The frontend then submits:

POST /reset-password

along with the token.

Backend Validation

Before updating the password, the backend verifies:

✅ Does the token exist?

✅ Has the token expired?

If either validation fails, the request is rejected.

This prevents attackers from reusing old reset links.

Updating the Password

Once the token is verified:

Hash the new password using bcrypt.
Update the password hash.
Remove the reset token.
Remove the expiration timestamp.

The token is deleted immediately after a successful password reset.

This guarantees that every reset link can be used only once.

Security Measures

Several security practices are implemented throughout the password reset workflow.

✅ Secure UUID token generation

✅ Token expiration (30 minutes)

✅ Password hashing using bcrypt

✅ Single-use reset links

✅ Email verification before reset

✅ Invalid token rejection

These practices significantly reduce the risk of unauthorized password changes.

Testing the Forgot Password Flow

Request

POST /forgot-password

{
    "userEmail":"sriya@gmail.com"
}

Response

{
    "success": true,
    "message": "Password reset token generated successfully"
}

The user receives a reset email.

Testing the Reset Password Flow

Request

POST /reset-password

{
    "token":"<reset-token>",
    "password":"NewPassword123"
}

Response

{
    "success": true,
    "message":"Password updated successfully"
}

Challenges Faced During Development

Implementing this feature wasn't completely straightforward.

Some of the challenges I encountered included:

SMTP IPv6 connection failures on Render.
Migrating from Nodemailer to Resend.
Missing environment variables during deployment.
Reset links returning Vercel 404 errors.
Debugging frontend routing after deployment.

Resolving these issues helped me gain a much deeper understanding of cloud deployment, environment management, and production debugging.

Summary

In this article we implemented:

Forgot Password API
Secure reset token generation
Token expiration
Database token storage
Email delivery using Resend
Reset Password API
Password update with bcrypt
Single-use reset links

Together, these features create a secure and user-friendly password recovery workflow commonly used in production applications.

What's Next?

The authentication system is now functionally complete.

In the next article, we'll implement Logout, understand why Refresh Tokens should be invalidated, and finally deploy the complete application to Render and Vercel, along with the production issues I encountered and how I resolved them.

Continue Reading Part 5 - https://dev.to/t_sriya_2af6abc7e8d4e87da/part-5-building-an-authentication-system-from-scratch-5h7

Live App: https://auth-flow-five-iota.vercel.app/auth/
Backend API: https://auth-flow-backend-1v2h.onrender.com/
github url: https://github.com/sriyaT/Auth-Flow

Connect : LinkedIn : https://www.linkedin.com/in/t-sriya-b4234510a/, github : https://github.com/sriyaT

Author: Sriya T.

Part 3 : Building an Authentication System from Scratch

t sriya — Thu, 02 Jul 2026 16:35:42 +0000

Secure User Authentication with JWT, Access Tokens & Refresh Tokens

Introduction

When a user registers, the application securely stores their credentials in the database. However, storing user information alone is not enough. The application also needs a secure mechanism to recognize authenticated users every time they interact with protected resources.

A login system should answer one simple question:

"How does the server know that this request is coming from an authenticated user?"

The traditional solution was server-side sessions, where the server stored session data in memory or a database. Modern applications, however, often rely on JSON Web Tokens (JWT) because they are lightweight, stateless, and highly scalable.

In this article, we'll build the complete login workflow using JWT, understand why Access Tokens and Refresh Tokens are required, and see how protected APIs verify user identity.

Login Flow

The login request follows the same layered architecture used throughout the project.

Client
   │
   ▼
Routes
   │
   ▼
Controller
   │
   ▼
Service
   │
   ▼
Repository
   │
   ▼
PostgreSQL

The workflow is:

User submits email and password.
Controller receives the request.
Service validates the credentials.
Repository retrieves the user from PostgreSQL.
bcrypt verifies the password.
JWT generates an Access Token.
JWT generates a Refresh Token.
Refresh Token is stored in PostgreSQL.
Both tokens are returned to the client.

Controller

The controller is responsible only for handling the incoming HTTP request.

Its responsibilities are:

Extract email and password.
Call the authentication service.
Return the generated tokens to the client.
Handle errors gracefully.

Service

The authentication service contains the complete login workflow.

It performs the following steps:

Find the user using the email address.
Verify the password using bcrypt.
Generate the JWT Access Token.
Generate the Refresh Token.
Save the Refresh Token in PostgreSQL.
Return user information along with both tokens.

Repository

The repository interacts directly with PostgreSQL.

For login, it performs operations such as:

Finding the user by email.
Updating the Refresh Token after successful authentication.

Keeping database logic isolated from business logic makes the application easier to maintain and test.

Verifying the Password

Although the password entered during login is plain text, the password stored in the database is already hashed.

Instead of converting the stored hash back into the original password (which is impossible), bcrypt hashes the entered password again using the salt embedded inside the stored hash.

const isMatch = await bcrypt.compare(
enteredPassword,
storedHash
);

Internally, bcrypt performs:

Entered Password

↓

Extract Salt from Stored Hash

↓

Hash Entered Password

↓

Compare Hashes

↓

true / false

If both hashes match, authentication succeeds.

Why JWT?

Once the user's identity has been verified, the server needs a way to recognize that user during future requests.

Instead of asking the user to submit their email and password for every API call, the server issues a JSON Web Token (JWT).

The client stores this token and includes it in every protected request.

Authorization: Bearer

This allows the server to authenticate the user without maintaining session data.

Anatomy of a JWT

A JWT consists of three sections.

`Header

Payload

Signature`

Example:

xxxxx.yyyyy.zzzzz
Header

Contains metadata.

{
"alg": "HS256",
"typ": "JWT"
}
Payload

Contains user claims.

{
"id": 1,
"email": "john@example.com"
}
Signature

Protects the token from tampering.

If someone modifies the payload, the signature immediately becomes invalid.

Why Access Token?

The Access Token is used to authenticate protected API requests.

Examples:

GET /profile

GET /dashboard

POST /logout

Instead of sending credentials repeatedly, the client simply sends:

Authorization: Bearer

Access Tokens are intentionally short-lived (typically 15 minutes to 1 hour).

Why Refresh Token?

If only Access Tokens existed, users would need to log in every time the token expired.

To improve user experience, a Refresh Token is also generated.

When the Access Token expires:

Access Token Expired

↓

Client sends Refresh Token

↓

Server verifies Refresh Token

↓

Generate New Access Token

↓

Continue Using Application

Refresh Tokens usually remain valid for several days.

Authentication Flow

User Login

↓

Verify Email & Password

↓

Generate Access Token

↓

Generate Refresh Token

↓

Store Refresh Token

↓

Return Tokens

↓

Client Stores Tokens

↓

Access Protected APIs

↓

Access Token Expires

↓

Use Refresh Token

↓

Generate New Access Token

JWT Middleware

Protected routes require authentication.

Instead of validating the JWT inside every controller, the application uses middleware.

The middleware:

Reads the Authorization header.
Extracts the JWT.
Verifies its signature.
Decodes the payload.
Attaches the authenticated user to the request.
Passes control to the controller.

If verification fails, the request is rejected.

Client

↓

JWT Middleware

↓

Verify Token

↓

Valid?

↓

Yes → Controller

No → 401 Unauthorized

Testing Login

Request:

POST /api/auth/login

{
    "email":"sriya@gmail.com",
    "password":"Password123"
}

Response:

{
  "success": true,
  "user": {
    "id": 1,
    "username": "Sriya",
    "email": "sriya@gmail.com"
  },
  "accessToken": "...",
  "refreshToken": "..."
}

Summary

In this article we:

Implemented secure user login.
Verified passwords using bcrypt.
Generated JWT Access Tokens.
Generated Refresh Tokens.
Stored Refresh Tokens in PostgreSQL.
Protected APIs using JWT middleware.
Built a stateless authentication system.
What's Next?

Now that users can authenticate successfully, the next step is handling one of the most common real-world scenarios:

Forgot Password

In the next article, we'll build a complete password recovery workflow using Resend, secure reset tokens, email delivery, and password reset validation.

Continue Reading Part 4 - https://dev.to/t_sriya_2af6abc7e8d4e87da/part-4-building-an-authentication-system-from-scratch-backend-setup-k2c

Live App: https://auth-flow-five-iota.vercel.app/auth/
Backend API: https://auth-flow-backend-1v2h.onrender.com/
github url: https://github.com/sriyaT/Auth-Flow

Connect : LinkedIn : https://www.linkedin.com/in/t-sriya-b4234510a/, github : https://github.com/sriyaT

Author: Sriya T.

Part 2 : Building an Authentication System from Scratch

t sriya — Thu, 02 Jul 2026 16:15:19 +0000

User Registration & Secure Password Hashing with bcrypt

In the previous article, we built the backend foundation by setting up Express.js, PostgreSQL, environment variables, and a clean layered architecture.

With the backend ready, it's time to implement the first authentication feature—User Registration.

Although registration appears straightforward, it involves much more than simply storing user details in a database. A secure registration system must validate user input, prevent duplicate accounts, protect passwords, and ensure that sensitive information is never exposed.

In this article, we'll build the complete registration workflow while following security best practices.

Registration Flow

The registration process follows a layered architecture, where each layer has a single responsibility.

Client
   │
   ▼
Routes
   │
   ▼
Controller
   │
   ▼
Service
   │
   ▼
Repository
   │
   ▼
PostgreSQL

The overall workflow is:

The client submits the registration form.
The controller receives the request.
The service validates the data.
The repository checks whether the email already exists.
The password is securely hashed using bcrypt.
The user is stored in PostgreSQL.
A success response is returned to the client.

Why a Layered Architecture?

Instead of placing all the registration logic inside the controller, I divided the implementation into three layers.

Controller

Responsible only for:

Receiving the HTTP request
Calling the service layer
Returning the HTTP response

The controller should never contain business logic or database queries.

Service

The service contains the application's business logic.

For registration, it is responsible for:

Validating the request
Checking whether the email already exists
Hashing the password
Calling the repository to save the user

This layer acts as the brain of the application.

Repository

The repository communicates directly with PostgreSQL.

Its responsibilities include:

Checking if a user already exists
Creating a new user
Executing SQL queries

Keeping SQL isolated inside repositories makes the application easier to maintain and test.

Controller

The controller receives the registration request and forwards the data to the service layer.

The controller itself performs very little work.

Its responsibility is simply to:

Extract the request body
Call the service
Return either a success or an error response

This keeps controllers lightweight and easy to understand.

Service

The service contains the actual registration workflow.

The registration service performs the following steps:

Check whether the email already exists.
Generate a secure password hash.
Create the user in PostgreSQL.
Return the newly created user.

Because all business rules live inside the service layer, future changes become much easier.

For example, adding email verification later would require changes only inside the service, without affecting controllers or repositories.

Repository

The repository is responsible only for database communication.

Typical repository functions include:

findByEmail()
createUser()

Keeping SQL queries isolated improves readability and keeps the service layer database-agnostic.

Why Password Hashing is Necessary

One of the biggest mistakes an application can make is storing passwords in plain text.

Imagine a database leak.

If passwords are stored as plain text, every user's credentials become immediately visible.

Instead, passwords should always be transformed into a secure one-way hash before being stored.

This is exactly why we use bcrypt.

Why bcrypt?

bcrypt is one of the most trusted password hashing libraries available for Node.js.

Unlike encryption, hashing is a one-way operation.

This means:

The original password cannot be recovered.
Even the application itself cannot view the user's password.
Only password verification is possible.

How bcrypt Works

When a user registers, bcrypt performs several operations internally.

Password
    │
    ▼
Generate Random Salt
    │
    ▼
Password + Salt
    │
    ▼
Multiple Hashing Rounds
    │
    ▼
Store Hash in Database

Each password receives its own randomly generated salt before hashing.

Because of this:

Two users with the same password will have completely different hashes.
Rainbow table attacks become ineffective.
Brute-force attacks become significantly slower due to bcrypt's configurable cost factor.

Password Verification During Login

During login, the user enters their password as plain text.

bcrypt then:

Reads the stored hash.
Extracts the embedded salt.
Hashes the entered password using the same salt.
Compares the generated hash with the stored hash.

If both hashes match, the user is successfully authenticated.

const isMatch = await bcrypt.compare(
    enteredPassword,
    storedHash
);

One of bcrypt's biggest advantages is that developers never need to manually manage salts or compare hashes—the library handles the entire verification process securely.

Security Benefits of bcrypt

Using bcrypt provides several important security advantages.

✅ Passwords are never stored in plain text.

✅ Every password uses a unique random salt.

✅ Identical passwords generate different hashes.

✅ Brute-force attacks become significantly slower.

✅ Rainbow table attacks are mitigated.

These features make bcrypt one of the industry standards for password protection.

Testing the Registration Flow

Once the backend implementation was complete, I verified the registration API using Postman.

Request

POST /api/auth/register

{
  "username": "Sriya",
  "email": "sriya@gmail.com",
  "password": "Password123"
}

Response

{
  "success": true,
  "user": {
    "id": 1,
    "username": "Sriya",
    "email": "sriya@gmail.com"
  }
}

Notice that the response never includes the password or its hash.

Only non-sensitive user information is returned to the client.

What's Next?

Now that users can securely register and their passwords are safely stored, the next step is allowing them to authenticate.

In the next article, we'll build the Login Flow, where we'll:

Verify user credentials
Compare passwords using bcrypt
Generate JWT Access Tokens
Generate Refresh Tokens
Understand how JWT authentication works internally

Continue Reading Part 3- https://dev.to/t_sriya_2af6abc7e8d4e87da/part-3-building-an-authentication-system-from-scratch-backend-setup-4119

Live App: https://auth-flow-five-iota.vercel.app/auth/
Backend API: https://auth-flow-backend-1v2h.onrender.com/
github url: https://github.com/sriyaT/Auth-Flow

Connect : LinkedIn : https://www.linkedin.com/in/t-sriya-b4234510a/, github : https://github.com/sriyaT

Author: Sriya T.

Part 1 : Building an Authentication System from Scratch – Backend Setup

t sriya — Thu, 02 Jul 2026 14:39:37 +0000

Setting up a scalable authentication backend using Node.js, Express.js, PostgreSQL, and a layered architecture.

Introduction__

Authentication is one of the most essential features of any modern web application. While many projects rely on third-party providers such as Firebase Auth, Auth0, or Clerk, I wanted to understand what actually happens behind the scenes when a user registers, logs in, resets their password, or logs out.

To achieve that, I decided to build a complete authentication system from scratch.

In this project, I implemented the entire authentication flow using:

React
Node.js
Express.js
PostgreSQL
JWT
Redux Toolkit
Tailwind CSS
Resend

The goal wasn't just to make authentication work—it was to understand the architecture, security considerations, and communication between the frontend, backend, and database.

This article is the first part of the series, where we'll build the backend foundation that powers the entire authentication system.

Project Structure

I prefer keeping both the frontend and backend inside a single project repository. This makes development, version control, and deployment much easier to manage.

Auth-Flow
│
├── auth-backend
│
└── auth-frontend

Inside the backend, I initialized a new Node.js application.

mkdir auth-project
cd auth-project

mkdir auth-backend
mkdir auth-frontend

cd auth-backend

mkdir server
cd server

npm init -y
Installing Dependencies

Next, I installed the packages required for building the authentication APIs.

npm install express pg bcrypt dotenv cors
npm install -D nodemon

Each package serves a specific purpose.

Package Purpose
Express Build REST APIs
pg Connect Node.js with PostgreSQL
bcrypt Securely hash passwords
dotenv Manage environment variables
cors Enable frontend-backend communication
nodemon Automatically restart the server during development

Instead of installing unnecessary libraries upfront, I only installed the packages required for the current stage of development. Additional libraries such as JWT and Resend will be introduced later as the project evolves.

Organizing the Backend

As applications grow, keeping everything inside a single file quickly becomes difficult to maintain.

To keep the project modular and scalable, I organized the backend into multiple layers.

server
│
├── src
│
│── controllers
│── services
│── repositories
│── middleware
│── routes
│── db
│── utils
│
├── server.js
└── package.json

Each folder has a clearly defined responsibility.

Controllers handle incoming HTTP requests and responses.
Services contain business logic.
Repositories interact with PostgreSQL.
Routes define API endpoints.
Middleware contains reusable request-processing logic.
DB manages database connections.
Utils stores helper functions.

This layered architecture keeps responsibilities separated and makes the codebase much easier to maintain and extend.

Setting Up PostgreSQL

Since user information needs to persist across sessions, I chose PostgreSQL as the database.

First, create the database.

CREATE DATABASE auth_project;

Then create the users table.

CREATE TABLE users (
   id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
   username VARCHAR(200) NOT NULL,
   email VARCHAR(250) NOT NULL UNIQUE,
   password_hash VARCHAR NOT NULL,
   created_at TIMESTAMP DEFAULT NOW()
);

Notice that the table stores password_hash instead of the user's original password. This is one of the most important security practices when building authentication systems.

Environment Variables

Sensitive information such as database credentials should never be hardcoded inside the application.

Instead, I created a .env file.

PORT=5000

DB_HOST=localhost
DB_PORT=5432
DB_USER=postgres
DB_PASSWORD=your_password
DB_NAME=auth_project

The .env file is excluded from version control.

node_modules
.env

This prevents sensitive credentials from being pushed to GitHub.

Creating the Database Connection

Instead of creating a new PostgreSQL connection inside every repository, I created a reusable database connection using pg.Pool.

const { Pool } = require("pg");

const pool = new Pool({
  host: process.env.DB_HOST,
  port: process.env.DB_PORT,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME,
});

module.exports = pool;

This single connection pool is shared throughout the application, improving performance and reducing resource usage.

Creating the Express Application

Next, I configured the Express server.

const express = require("express");
const cors = require("cors");

const app = express();

app.use(express.json());

app.use(
  cors({
    origin: "http://localhost:5173",
    credentials: true,
  })
);

module.exports = app;

At this stage, the server is capable of:

Parsing JSON request bodies
Accepting requests from the React frontend
Preparing for future authentication middleware
Server Entry Point

The application starts from server.js.

require("dotenv").config();

const app = require("./src/app");

const PORT = process.env.PORT || 5000;

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Running

npm run dev

starts the backend server.

Server running on port 5000
Verifying the Backend

Before implementing authentication, I always verify that the server is functioning correctly.

I added a simple health-check endpoint.

router.get("/", (req, res) => {
  res.json({
    status: "ok",
  });
});

Request:

GET /health

Response:

{
"status": "ok"
}

This confirms that the backend is configured correctly before moving on to authentication.

Why I Chose a Layered Architecture

One mistake I often see in beginner projects is placing SQL queries directly inside controllers.

Instead, I separated responsibilities into three layers.

Controller
│
▼
Service
│
▼
Repository
│
▼
PostgreSQL
Controller

Receives the HTTP request and returns the HTTP response.

Service

Contains all business logic, including:

Email validation
Password hashing
JWT generation
Authentication rules
Repository

Handles database operations only.

This separation makes the project easier to:

Debug
Test
Scale
Maintain

As more authentication features are added, each layer continues to have a single responsibility.

Conclusion

With the backend infrastructure now in place, the application is ready to implement authentication features.

In the next article, we'll build the User Registration Flow, where we'll:

Validate user input
Prevent duplicate accounts
Securely hash passwords using bcrypt
Store users in PostgreSQL
Return a safe API response

Continue Reading Part 2: https://dev.to/t_sriya_2af6abc7e8d4e87da/part-2building-an-authentication-system-from-scratch-backend-setup-59gg

Live App: https://auth-flow-five-iota.vercel.app/auth/
Backend API: https://auth-flow-backend-1v2h.onrender.com/
github url: https://github.com/sriyaT/Auth-Flow

Connect : LinkedIn : https://www.linkedin.com/in/t-sriya-b4234510a/, github : https://github.com/sriyaT

Author: Sriya T.