How JWT Authentication Works in a Modern Web Application

Sat, 03 Oct 2026 13:11:42 +0000

Authentication is one of the most important parts of modern web application development. Whether we are building an e-commerce platform, a social media application, a SaaS dashboard, or a REST API, we need a reliable way to identify users and control access to protected resources.

Imagine opening an online shopping website, logging into your account, adding products to your cart, and checking your order history. Even when you navigate between different pages, the application remembers who you are. This seamless experience is made possible through authentication mechanisms.

One popular approach used by modern applications is JSON Web Token (JWT) authentication.

JWT provides a compact, URL-safe method for transferring information between parties. It is widely used in applications built with React, Next.js, Node.js, Express, Django, FastAPI, and other modern technologies.

However, JWT is more than simply generating a token after login. Understanding how tokens are created, signed, verified, stored, refreshed, and invalidated is essential for building secure applications.

In this article, we will explore how JWT authentication works, its architecture, implementation steps, security considerations, common mistakes, and practical use cases in modern full-stack development.

1. What Is JWT Authentication?

JWT stands for JSON Web Token. It is an open standard defined by RFC 7519 that describes a compact way to represent claims between two parties.

A JWT is commonly used to communicate information about an authenticated user from a client application to a backend server.

For example, after a successful login, a server may issue a token containing information such as:

User ID
User role
Token expiration time
Issuer
Audience
Other application-specific claims

The client can then present this token when requesting protected resources.

Instead of sending the user's email and password with every request, the client sends a token that the backend can verify.

A typical JWT looks like this:

xxxxx.yyyyy.zzzzz

It consists of three parts separated by dots:

Header
Payload
Signature

These three components work together to make JWT useful for authentication and secure information exchange.

2. Understanding the Three Parts of a JWT

The header contains metadata about the token, including its signing algorithm and token type.

Example:

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

Here:

alg identifies the signing algorithm.
typ indicates that the token is a JWT.

The header is encoded using Base64URL encoding.

Payload

The payload contains claims, which are statements about a user or another entity.

Example:

{
  "sub": "user_1024",
  "name": "Siddiqur Rahman",
  "role": "admin",
  "iat": 1790964000,
  "exp": 1790967600
}

Some commonly used claims include:

sub: Subject, often the user ID.
iat: Issued-at timestamp.
exp: Expiration timestamp.
iss: Token issuer.
aud: Intended audience.

The payload is also Base64URL encoded.

An important security point is that Base64URL encoding is not encryption. Anyone who obtains a normal signed JWT can decode its header and payload.

Therefore, passwords, payment information, private keys, and sensitive personal data should never be placed inside a JWT payload.

Signature

The signature protects the integrity of the token.

For an HMAC-based JWT, the signature is generated using the encoded header, encoded payload, and a secret key.

Conceptually:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

When the client sends the token back, the server verifies its signature.

If someone modifies the payload without access to the signing key, signature verification fails.

This is why JWTs can provide tamper detection.

3. How JWT Authentication Works: Step by Step

Let's understand the complete authentication lifecycle through a practical example.

Suppose we are developing a full-stack application using:

Frontend: React or Next.js
Backend: Node.js and Express
Database: PostgreSQL
Authentication: JWT
Password hashing: bcrypt

The authentication process typically follows these steps.

Step 1: User Registration

A new user creates an account by providing an email address and password.

The frontend sends the registration information to the backend.

POST /api/auth/register
Content-Type: application/json

{
  "email": "*Emails are not allowed*",
  "password": "StrongPassword123!"
}

The backend validates the input and checks whether the email already exists.

Before saving the password, the application hashes it using a password-hashing algorithm such as bcrypt or Argon2.

The database stores the password hash rather than the original password.

This is an essential security practice because passwords should never be stored in plaintext.

When the user logs in, the frontend sends their credentials to the authentication endpoint.

POST /api/auth/login

{
  "email": "*Emails are not allowed*",
  "password": "StrongPassword123!"
}

The backend retrieves the user record from PostgreSQL and compares the submitted password against the stored password hash.

If the credentials are incorrect, the server rejects the request.

If the credentials are valid, the backend creates a signed JWT.

Step 3: Server Generates the JWT

After successful authentication, the backend creates a token containing the necessary claims.

Example using Node.js:

const jwt = require("jsonwebtoken");

const accessToken = jwt.sign(
  {
    sub: user.id,
    role: user.role
  },
  process.env.JWT_SECRET,
  {
    expiresIn: "15m",
    issuer: "my-web-app",
    audience: "my-web-client"
  }
);

The server signs the token using a secret stored in an environment variable.

The expiration time limits how long the access token can be used.

For sensitive applications, short-lived access tokens combined with a carefully designed refresh-token mechanism can reduce the impact of token theft.

Step 4: Client Receives the Token

After authentication, the server returns the access token or sets it in a secure cookie.

A simplified JSON response might look like this:

{
  "message": "Login successful",
  "accessToken": "eyJhbGciOiJIUzI1NiIs..."
}

In production applications, token delivery and storage must be designed carefully.

For browser-based applications, an HttpOnly, Secure cookie with an appropriate SameSite policy is often a useful approach.

HttpOnly prevents JavaScript from reading the cookie directly, reducing the risk of token theft through certain cross-site scripting attacks.

Step 5: Client Sends the Token with Requests

When the user accesses a protected endpoint, the client includes the access token.

For example:

GET /api/profile
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

The word Bearer indicates that the request is presenting a bearer token.

The backend receives the token and passes it to authentication middleware.

Step 6: Server Verifies the JWT

The backend checks whether the token is valid.

It verifies:

Signature
Expiration time
Issuer
Audience
Expected signing algorithm

If the token is invalid or expired, the server rejects the request.

If verification succeeds, the backend can identify the authenticated user using the token's subject claim.

Step 7: Access to Protected Resources

Once authentication succeeds, the application can continue processing the request.

For example, a profile endpoint may return the authenticated user's information.

However, authentication and authorization are different concepts.

Authentication answers:

"Who are you?"

Authorization answers:

"What are you allowed to do

A valid JWT does not automatically grant administrator permissions. The backend must still enforce role-based or resource-based access controls.

4. JWT Authentication Architecture

A modern application typically contains several components that work together.

Frontend

The frontend handles login forms, user interactions, and authenticated API requests.

Technologies include React, Next.js, Angular, and Vue.

Backend

The backend manages authentication, token creation, verification, permissions, and protected routes.

Technologies include Express, NestJS, Django, FastAPI, and Spring Boot.

Database

The database stores user information, password hashes, roles, and refresh-token session records when required.

PostgreSQL, MySQL, and MongoDB are common choices.

Authentication Middleware

Middleware verifies incoming tokens before allowing access to protected routes.

A simplified Express example:

function authenticateToken(req, res, next) {
  const authHeader = req.headers.authorization;

  const token = authHeader?.split(" ")[1];

  if (!token) {
    return res.status(401).json({
      message: "Authentication required"
    });
  }

  try {
    const decoded = jwt.verify(
      token,
      process.env.JWT_SECRET,
      {
        algorithms: ["HS256"],
        issuer: "my-web-app",
        audience: "my-web-client"
      }
    );

    req.user = decoded;
    next();

  } catch (error) {
    return res.status(401).json({
      message: "Invalid or expired token"
    });
  }
}

This middleware verifies the token before passing control to the next function.

In a production application, error handling, key management, logging, and authorization checks should also be carefully implemented.

5. Access Tokens vs. Refresh Tokens

One of the most important concepts in modern JWT authentication is the difference between access tokens and refresh tokens.

Access Token

An access token is used to access protected APIs.

Typical characteristics:

Short expiration period
Sent with API requests
Contains limited claims
Used to authenticate requests

For example, an application might configure a 15 minute lifetime.

Refresh Token

A refresh token is used to obtain a new access token without requiring the user to log in again.

Typical characteristics:

Longer lifetime
Stored more carefully
Used only with a refresh endpoint
Can be rotated and revoked

A refresh token may be an opaque random value rather than a JWT. JWT is not mandatory for refresh tokens.

How Token Refresh Works

Consider a user working on a dashboard.

The user logs in successfully.
The server issues an access token and a refresh token.
The access token expires after a short period.
The frontend sends the refresh token to the refresh endpoint.
The backend validates the refresh session.
The backend issues a new access token.
The refresh token may also be rotated.
The user continues working without entering credentials again.

Refresh-token rotation helps detect reuse of an older token, particularly when token families and session revocation are implemented correctly.

6. Where Should JWTs Be Stored.

Token storage is one of the most discussed topics in web security.

There are several approaches, and each has different security trade-offs.

LocalStorage

LocalStorage allows JavaScript to access stored values.

Advantages:

Simple to implement
Persists across browser refreshes
Convenient for certain client-side applications

Disadvantages:

Accessible to JavaScript
Can be exposed through successful XSS attacks
Requires careful token lifecycle management

Storing long-lived authentication tokens in LocalStorage is generally discouraged for sensitive browser applications.

SessionStorage

SessionStorage is scoped to a browser tab and is cleared when that tab's session ends.

However, JavaScript can still access it, so it does not eliminate XSS-related token theft risks.

HttpOnly Cookies

HttpOnly cookies cannot be read directly by JavaScript.

A secure cookie may use settings such as:

Set-Cookie: refreshToken=example;
HttpOnly;
Secure;
SameSite=Strict;
Path=/api/auth;

The exact cookie policy depends on the application's domain structure and authentication flow.

Cookies reduce certain token-exposure risks, but cookie-based authentication also requires protection against cross-site request forgery (CSRF) where applicable.

A secure implementation may combine SameSite settings, CSRF tokens, origin validation, and appropriate cookie scope.

7. JWT Authentication with Role-Based Access Control

Modern applications often support different types of users.

For example:

Admin
Manager
Customer
Editor
Support agent

JWT can carry a role claim, but the backend must enforce the actual permissions.

Example:

function authorizeRole(...allowedRoles) {
  return (req, res, next) => {
    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({
        message: "Access denied"
      });
    }

    next();
  };
}

Usage:

app.get(
  "/api/admin/dashboard",
  authenticateToken,
  authorizeRole("admin"),
  (req, res) => {
    res.json({
      message: "Welcome to the admin dashboard"
    });
  }
);

A user without the required role receives a forbidden response.

For applications with complex permissions, the backend should also check ownership, organization membership, and resource-level access.

A role claim inside a token should not be treated as permanently authoritative if permissions can change during the token's lifetime. Short token lifetimes or server-side authorization checks can address this concern.

8. JWT Authentication in a Next.js Application

Next.js is widely used for building full-stack web applications.

A typical architecture may include:

Next.js frontend
API routes or route handlers
PostgreSQL database
JWT-based access tokens
Secure cookie sessions

A login route can validate credentials and issue a token.

A simplified example:

import jwt from "jsonwebtoken";
import { cookies } from "next/headers";

export async function POST(request) {
  const { email, password } = await request.json();

  // Validate credentials against the database.
  const user = await validateUser(email, password);

  if (!user) {
    return Response.json(
      { message: "Invalid credentials" },
      { status: 401 }
    );
  }

  const token = jwt.sign(
    { sub: user.id },
    process.env.JWT_SECRET,
    { expiresIn: "15m" }
  );

  const cookieStore = await cookies();

  cookieStore.set("accessToken", token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "lax",
    path: "/",
    maxAge: 900
  });

  return Response.json({
    message: "Login successful"
  });
}

This is an illustrative example. A complete production implementation should also validate input, handle database errors, configure token issuer and audience, and implement logout and refresh-session behavior.

Next.js developers can also use established authentication libraries when their session-management requirements are more complex than a custom implementation.

9. JWT Security Best Practices

JWT makes authentication convenient, but incorrect implementation can create serious security vulnerabilities.

Here are important practices developers should follow.

1. Use HTTPS

Always use HTTPS in production.

HTTPS protects authentication tokens while they travel between the browser and server.

2. Use Strong Signing Keys

Never use predictable secrets such as:

secret123
password
myjwtkey

Use a cryptographically secure key and keep it outside the source code.

For larger systems, asymmetric signing algorithms such as RS256 or ES256 may be appropriate because services can verify tokens using public keys without possessing the private signing key.

3. Keep Access Tokens Short-Lived

Short-lived access tokens reduce the period during which a stolen token can be used.

Choose expiration periods based on application risk, user experience, and revocation requirements.

4. Validate the Signing Algorithm

Do not blindly trust the algorithm declared in the token header.

Configure the server to accept only the intended algorithms.

5. Validate Issuer and Audience

Check the iss and aud claims where applicable.

This helps prevent a token issued for one service or application from being accepted by another unintended service.

6. Avoid Sensitive Data in the Payload

JWT payloads are usually readable by anyone who obtains the token.

Store only the claims required for authentication and authorization.

7. Implement Logout and Revocation

A stateless access token does not automatically become invalid when a user logs out.

Applications can manage this using refresh-token revocation, session records, token deny-lists, or other server-side controls.

8. Protect Against XSS and CSRF

Use secure development practices, including output escaping, content security policies, secure cookies, CSRF protection where needed, and strict input validation.

JWT alone does not solve these vulnerabilities.

9. Rotate Refresh Tokens

Refresh-token rotation limits the usefulness of stolen refresh tokens and can help detect suspicious reuse.

10. Never Store Passwords in JWTs

JWTs are authentication credentials, not password storage containers.

Passwords should be hashed using an appropriate password-hashing algorithm and stored securely.

10. Common JWT Authentication Mistakes

Even experienced developers can make mistakes when implementing authentication.

Some common examples include:

Using JWT as encryption: A signed JWT is not automatically encrypted. Encoding does not provide confidentiality.

Using tokens without expiration: Long-lived tokens increase the impact of credential theft.

Ignoring token revocation: Stateless authentication still needs a strategy for logout, compromised sessions, and account changes.

Trusting frontend roles: Hiding an admin button in React does not prevent unauthorized API access.

Putting secrets in frontend code: Signing keys must remain on trusted backend infrastructure.

Accepting any JWT algorithm: Verification should use an explicit algorithm allowlist.

Ignoring refresh-token security: Refresh tokens need careful storage, rotation, expiration, and revocation policies.

Skipping authorization checks: A valid token proves an identity claim, not permission to access every resource.

Understanding these mistakes helps developers build authentication systems that are both practical and secure.

11. JWT vs. Traditional Session-Based Authentication

JWT authentication is not the only way to manage user sessions.

Traditional session-based authentication stores session state on the server and typically sends the browser a session identifier in a cookie.

JWT authentication often allows services to verify signed claims without looking up a session on every request.

However, JWT does not automatically make an application faster, more scalable, or more secure. The actual result depends on architecture and implementation.

Feature	JWT-Based Authentication	Session-Based Authentication
Main credential	Signed token	Session identifier
Server-side state	Can be minimized	Usually maintained
Revocation	Requires additional design	Often straightforward
API use	Common	Also widely supported
Browser storage	Cookie or other client storage	Usually cookie
Scaling	Verification can be distributed	Requires shared session storage or affinity
Logout	May require revocation mechanisms	Session can be invalidated server-side

For many traditional web applications, server-side sessions are an excellent option.

For distributed APIs and services, JWT may be useful when its verification and lifecycle requirements fit the architecture.

The correct choice depends on the application's security requirements, deployment model, and operational complexity.

12. Real-World Use Cases of JWT

JWT authentication is used in different types of modern software systems.

E-commerce Applications

Users can log in, view orders, manage addresses, and access account-specific features.

SaaS Platforms

JWT may be used to authenticate requests to dashboards, APIs, and organization-based services.

Mobile Applications

Mobile clients can use access and refresh tokens to authenticate API requests, with secure platform storage and careful refresh-token handling.

Microservices

A trusted identity provider can issue tokens that multiple services verify using shared or distributed public keys.

Admin Dashboards

JWT authentication can be combined with role-based permissions to protect administrative APIs.

Third-Party API Integrations

JWT is also used in certain server-to-server authentication systems and signed authorization assertions.

These examples demonstrate why understanding JWT is valuable for full-stack developers.

13. The Future of Authentication

Authentication continues to evolve as web applications become more distributed and security requirements grow.

Modern systems increasingly combine multiple technologies:

OAuth 2.0 for delegated authorization
OpenID Connect for identity authentication
Multi-factor authentication
Passkeys and WebAuthn
Short-lived access tokens
Refresh-token rotation
Centralized identity providers
Risk-based authentication

JWT is often part of these systems, but it is not a complete authentication protocol by itself.

Developers should understand the difference between token formats, authentication protocols, identity management, and authorization.

Choosing the right combination helps create applications that are easier to maintain and more resistant to common attacks.

Conclusion

JWT authentication is an important concept in modern full-stack development. It provides a compact way to represent signed claims and allows applications to verify authentication information across frontend and backend systems.

From user registration and login to token verification, refresh-token rotation, and role-based access control, every part of the authentication lifecycle contributes to application security.

However, using JWT does not automatically make an application secure. Developers must carefully handle token storage, expiration, signing keys, authorization, revocation, HTTPS, XSS, and CSRF protection.

For developers working with React, Next.js, Node.js, PostgreSQL, or modern REST APIs, understanding JWT is a valuable step toward building reliable production applications.

The goal is not simply to make login work. It is to build an authentication system that protects users, respects permissions, and remains maintainable as the application grows.

Secure authentication is not just a backend feature. It is a fundamental part of building trustworthy software.

Coder Legion - Recent posts tagged jwtauthentication

How JWT Authentication Works in a Modern Web Application

1. What Is JWT Authentication?

2. Understanding the Three Parts of a JWT

Header

Payload

Signature

3. How JWT Authentication Works: Step by Step

Step 1: User Registration

Step 2: User Login

Step 3: Server Generates the JWT

Step 4: Client Receives the Token

Step 5: Client Sends the Token with Requests

Step 6: Server Verifies the JWT

Step 7: Access to Protected Resources

4. JWT Authentication Architecture

Frontend

Backend

Database

Authentication Middleware

5. Access Tokens vs. Refresh Tokens

Access Token

Refresh Token

How Token Refresh Works

6. Where Should JWTs Be Stored.

LocalStorage

SessionStorage

HttpOnly Cookies

7. JWT Authentication with Role-Based Access Control

8. JWT Authentication in a Next.js Application

9. JWT Security Best Practices

1. Use HTTPS

2. Use Strong Signing Keys

3. Keep Access Tokens Short-Lived

4. Validate the Signing Algorithm

5. Validate Issuer and Audience

6. Avoid Sensitive Data in the Payload

7. Implement Logout and Revocation

8. Protect Against XSS and CSRF

9. Rotate Refresh Tokens

10. Never Store Passwords in JWTs

10. Common JWT Authentication Mistakes

11. JWT vs. Traditional Session-Based Authentication

12. Real-World Use Cases of JWT

E-commerce Applications

SaaS Platforms

Mobile Applications

Microservices

Admin Dashboards

Third-Party API Integrations

13. The Future of Authentication

Conclusion

JWTAuthentication #FullStackDevelopment #WebSecurity