What I've learned about JWT authentication

Introduction

Authentication VS Authorization

Before entering in how JWT works I want to talk about this very important concepts in BackEnd Development.

• Authentication: The process of verifying that someone is who they claim to be. For example, as a user, I prove my identity by providing credentials such as a password. The system then checks these credentials and confirms that I am a registered user, allowing me to log in once my identity is authenticated;
• Authorization: The process of verifying whether an authenticated user has permission to perform a specific action. For example, if a normal user tries to access the admin page, the system knows who they are because they are authenticated and now checks if they have the necessary permissions to access it.

The Two Most Popular Authentication Strategies

Session-Based Authentication

This is the simplest authentication method. It follows these steps:

• The user sends their credentials to the backend.
• If the credentials are valid, the system creates a session entry in the database (often in-memory, like Redis).
• The server sends a session_id to the frontend.
• When the user tries to access a protected route, the server checks the database to see if there is an active session corresponding to the session_id.
• If a valid session exists, the user is allowed to access the resource.

Advantages:

• Easy to implement.
• Immediate session revocation is possible.

Disadvantages:

• Performance can be affected because the database must be queried on almost every request.
• If the session_id is stolen, it can be used until it expires.

---

JWT-Based Authentication

This method works as follows:

• The user sends their credentials to the backend.

• After verifying the credentials, the server sends a JSON Web Token (JWT), which is a Base64-encoded token containing:

  • User information (claims)
  • Expiration time
  • A signature created using a secret key to ensure the token's integrity

• When the user tries to access a protected route, the server validates the token by checking its signature and expiration.

• If the token is valid and not expired, the user is allowed to access the resource.

A key aspect of JWTs is that they are stateless, meaning no session information is stored on the server. The token is self-contained, and its authenticity relies entirely on the secret used to sign it.

Advantages:

• High performance: no database lookups are required to verify the token.
• Scalability: easier to use in distributed systems since sessions don’t need to be shared.

Disadvantages:

• Revoking tokens is difficult: once issued, they remain valid until they expire unless additional mechanisms are implemented (e.g., token blacklisting).
• If the secret is compromised, all issued tokens can be forged.

The Best of Both Worlds: JWT with Refresh Tokens

Recently, I implemented this method on Sunlog.dev. Here's how it works:

• The user sends their credentials to the backend.
• The backend verifies them and returns two tokens to the frontend:
  • access_token: Used to make requests to the API, with a short expiration time (e.g., 15 minutes).
  • refresh_token: Stored in a database (e.g., Redis), allowing the frontend to request a new access_token. It has a longer expiration (e.g., 15 days).
• When the access_token expires, the frontend sends a request to a special endpoint (e.g., /auth/refresh) with the refresh token.
• The server verifies the refresh token and checks for a stored entry for the corresponding user.
• If valid, it issues a new access_token to the frontend.

An Extra Feature: Refresh Token Rotation

With refresh token rotation, every refresh request issues a new refresh token and invalidates the old one. This improves security and ensures a smoother user experience - users won't be logged out if they visit the site regularly.

Advantages:

• High performance: The server only checks the database when refreshing the access token, not on every request.
• Easy session revocation: Deleting the refresh token from the database limits the access token's validity.
• Reduced risk if tokens are stolen: Access tokens are short-lived, and rotated refresh tokens are invalidated after use.
• Better UX: Regular users who interact with the site before their refresh token expires won't be logged out.

Disadvantages:

• More complex implementation: Requires extra logic in both the backend and frontend.

Conclusion

Implementing JWT authentication, especially combined with refresh tokens and token rotation, provides a robust and scalable approach for securing modern web applications. While simple session-based authentication can be easier to implement, it doesn't scale as well and can introduce performance and security challenges.

On the other hand, JWTs allow stateless authentication, which works great in distributed systems, and when combined with refresh tokens, we get the best of both worlds: good performance, better security, and an improved user experience.

In practice, using refresh token rotation ensures that even if a token is compromised, the potential damage is minimized, while users who actively interact with the site remain logged in seamlessly.

I found implementing JWT with refresh tokens somewhat challenging, but it was definitely worth it. Without a doubt, it’s an essential topic for backend developers.