Introduction

Authentication is one of the most critical aspects of modern applications, yet it's often one of the most misunderstood by beginners — and I was no exception. I began with a simple username-password check and session handling, but quickly realized that wasn’t enough for real-world security.

In this blog, I’ll walk through what I’ve learned—from basic setups to more secure methods like email verification, password hashing, and token-based authentication inspired by OAuth2.

My initial approach on Authentication

When I first started building web applications, authorization was one of the most confusing parts of the development process. I wasn’t sure what the best practices were for securely verifying users on a website or platform. Like many beginners, I followed a simple approach: collect the username and password from the user, verify the credentials on the server, and if they were correct, generate a session cookie with an expiration date to keep the user logged in. This method ensured that users remained authenticated as long as the session cookie was valid.

But as I gained more experience, I realized there had to be a better way to handle authorization.

Email verification

The initial approach I used felt too naive — anyone with a valid username and password could log in, even if the credentials were obtained through insecure means. I realized there needed to be an additional layer of validation to ensure that the person logging in was indeed the rightful owner of the account.

This led me to explore email verification flows. Instead of granting access immediately after verifying credentials, I added a step where users received a verification link or a one-time password (OTP) via email. The user would have to confirm their email address before being fully authenticated.

A Better Way to Handle Authentication

While email verification added an extra layer of security, I soon realized it still wasn’t enough — especially when building a custom authentication and authorization system for web or mobile applications. Unlike third-party providers like Google or Facebook.

One of the most critical aspects of building a secure auth system is password hashing. Storing raw or even weakly hashed passwords is a major security risk.

Why does Password Hashing Matter?

Whenever a user registers, their password should never be stored as plain text. Instead, it must be hashed using a strong algorithm (e.g., bcrypt ) before storing it in the database.

In addition to hashing, you must use a unique salt — a secret value added to the password before hashing. Each user should be assigned a unique salt, and it should be stored alongside the hashed password in your database.

This might seem like a small detail, but it’s a critical one. In fact, millions of LinkedIn user passwords were compromised in a major breach because they used the SHA-1 algorithm without salting the passwords.

Hashing with a salt ensures that even if two users have the same password, their stored hashes will be completely different — making it significantly harder for attackers to reverse-engineer them.

Concepts of OAuth2

As I continued learning more about authentication, I began exploring OAuth2 — a powerful and flexible authorization framework. While OAuth2 is a vast protocol used in many different ways (like integrating third-party logins such as Google), my focus here is on how its core concepts can help you build a better custom authorization system for your own application.

Clarifying OAuth2 vs Custom Auth Systems

While OAuth2 is a widely used framework for authorization, it's important to clarify that it's primarily designed for delegated access — allowing third-party applications to access user data from another service (like Google) without needing the user's credentials.

In contrast, what I’ve implemented in my application is a custom authentication system that uses token-based security principles inspired by OAuth2, such as access and refresh tokens. These concepts help improve security, scalability, and session management in your own application

Implementing Token-Based Authentication (Inspired by OAuth2 Principles)

Whenever the user logs into the website or app, they enter their credentials. As soon as the credentials reach the server, the server validates the password using the user’s specific salt, and then generates both an access token and a refresh token, sending them back to the client, once the user receives it user saves the token securely (and in mobile application the tokens are encrypted with the app password).

• 

  Access Token:- It is a short-lived token that authorizes the user to access protected resources. It is included in the headers of each HTTP request (usually in the authorization header) and server middleware validate that token before processing the request.

• Refresh Token: It is a long-lived token used to obtain a new access token when the original one expires. This allows users to stay logged in for extended periods without having to re-enter their credentials.

What Happens When the Access Token Expires?

1. The client uses the refresh token to request a new access token from the server.

2. The server validates the refresh token.

3. If valid, the server generates a new access token and optionally a new refresh token, and sends them to the client.

4. The client stores these new tokens securely and uses the new access token for subsequent requests.

Why should you issue a New Refresh Token?

You might be thinking — "Why generate a new refresh token every time? Isn't it long-lived anyway?"

That’s a good question. In many systems, it’s valid to use the same refresh token until it expires. However, generating a new refresh token with every token refresh has its advantages:

• It helps ensure that active users stay logged in indefinitely without needing to reauthenticate.

• Generating a new refresh token each time ensures that the token's expiration keeps extending as long as the user actively uses the web or mobile application. However, if the user becomes inactive and doesn't access the platform for an extended period (such as several months), the refresh token will eventually expire, automatically logging the user out.

• It reduces the attack surface in case a token is leaked, as old refresh tokens can be invalidated automatically when new ones are issued.

• It provides a graceful logout path for inactive users — if they don’t open the app for a long period, the refresh token eventually expires and forces reauthentication.

Conclusion

Authentication can seem complex at first, but understanding the core principles—like email verification, password hashing with salt, and token-based auth—makes it much more manageable. Inspired by OAuth2, I built a custom system using access and refresh tokens to improve both security and user experience.

While there’s always more to learn, building this foundation helped me grow as a developer and better understand what secure authentication really means.
I’ll be covering Google Authentication in my upcoming blog — stay tuned!