JWT Token Explained: How Modern Authorization Works Without Sessions

JWT token is one of the most popular authorization methods in modern web applications. It's used in APIs, mobile apps, and services with microservice architecture because it allows you to operate without storing sessions on the server.

Previously, the server had to remember each user (via sessions), but with JWT, things work differently: all information is transmitted along with each request. This makes the system faster, easier to scale, and more convenient for distributed services.

In this article, we'll explore what a JWT token is, how it works, what it consists of, and how it differs from classic sessions.

JWT Token Explained in Simple Terms

A JWT token is a special string that stores information about a user and is used to identify them without the need to keep data on the server. JWT stands for JSON Web Token.

In simple terms, it's a "digital pass" you receive after logging into a system. Instead of verifying the user through the database each time, the server just reads the token and understands who you are and what you're allowed to do.

JWT is actively used in modern web applications, mobile apps, and APIs. For example:

• when logging into a website
• when authorizing via apps
• when working with REST APIs

The main idea of JWT is that all information is stored inside the token itself, not on the server. This makes the system faster and easier to scale.

The token usually looks like a long string separated by dots, for example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Although it seems like a random set of characters, it actually contains:

• user information (ID, role)
• expiration time
• a signature that protects the data from tampering

It's important to note: JWT does not encrypt data, it only encodes it. This means the content can be decoded, but cannot be changed without breaking the signature.

JWT has become popular because it enables authorization without sessions. The server doesn't need to store user state-all necessary information is already inside the token.

How Does a JWT Token Work?

The operation of a JWT token is based on a simple idea: the server issues the token once, then just checks it with each request, without storing the user's state.

Let's break down the process step by step.

1. The user enters their login and password. This data is sent to the server, which verifies it-usually via a database.
2. If the credentials are correct, the server creates a JWT token. Inside, it records:
   • user ID
   • role (e.g., user or admin)
   • expiration time
3. The token is then sent to the client-browser or app.
4. There are several storage options:
   • localStorage
   • sessionStorage
   • cookie (usually HttpOnly for security)
5. After receiving the token, the key phase begins-using it. Each subsequent request to the server is sent with the token, usually in the header:
   Authorization: Bearer <token>
6. When the server receives a request, it:
   1. Extracts the token
   2. Checks its signature
   3. Checks its expiration time
   4. Extracts data from the payload
   If everything is correct, the user is considered authorized and the request proceeds.

Important: The server does not store any user information between requests. Everything it needs is inside the token. That's why JWT is called a stateless approach.

This mechanism is especially convenient for:

• APIs
• microservices
• distributed systems

JWT is often used together with OAuth-learn more in the article How OAuth 2.0 Works: Secure Login Without Passwords.

Structure of a JWT Token

A JWT token consists of three parts, separated by dots:

header.payload.signature

Each part is Base64-encoded, so the token appears as a string of characters, but it actually contains a readable structure.

1. Header

Contains information about the token type and the signature algorithm.

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

• alg - signature algorithm (e.g., HMAC SHA-256)
• typ - token type

2. Payload

This is the main part of the token, where information is stored.

{
  "userId": 123,
  "role": "admin",
  "exp": 1712345678
}

It may include:

• user data
• access rights
• expiration time (exp)
• creation time (iat)

Important: The payload is not encrypted, only encoded. Anyone can read it.

3. Signature

This is the most important part, protecting the token from forgery.

The signature is created using:

• header
• payload
• a secret key (on the server)

If someone tries to modify data inside the token, the signature won't match, and the server will reject the request.

In summary, a JWT is not just a string, but a self-contained data container with protection. The server doesn't need to query the database to understand who it's dealing with-all the info is inside the token.

JWT Authorization vs. Authentication-What's the Difference?

When working with JWT, two concepts are often confused: authentication and authorization. They are related, but serve different purposes.

Authentication

This is the process of verifying a user's identity. In other words, the system answers: "Who are you?"

Example:

• User enters login and password
• Server checks the credentials
• If correct, the user is confirmed

It's at this stage that the JWT token is usually created.

Authorization

This is the next step. The system answers: "What are you allowed to do?"

For instance:

• A regular user can read data
• An administrator can modify data

This information is stored inside the JWT-usually in the payload (for example, the role field).

How JWT participates in these processes:

1. User is authenticated (logs in)
2. Server issues a JWT token
3. The token already contains access rights
4. On each request, the server performs authorization by reading data from the token

So, JWT combines both processes:

• confirms identity
• stores access rights

Note: JWT itself does not perform authentication. It only stores the result, which was obtained after verifying the user.

JWT vs. Sessions-What's the Difference?

To understand the value of JWT, it's important to compare it with the classic approach-sessions.

How Sessions Work

After a user logs in, the server:

• creates a record in memory or a database
• assigns a session ID to the user
• sends this ID in a cookie

On each subsequent request:

• The browser sends the session ID
• The server looks up data in storage
• Determines who the user is

This means the server stores the user's state.

How JWT Works

Instead of storing data on the server:

• The server creates a token with information
• Sends it to the client
• The client stores the token
• With each request, the token is sent back

The server doesn't look anything up in the database-it just checks the token.

Key Differences

1. Data Storage
   • Sessions: on the server
   • JWT: inside the token
2. Scalability
   • Sessions: more difficult (requires shared storage)
   • JWT: easier (servers are independent)
3. Performance
   • Sessions: every time, access to database or memory
   • JWT: signature verification only, no extra queries
4. Security
   • Sessions: can be invalidated on the server
   • JWT: harder to revoke (once the token is issued)

When JWT is Better

• APIs and microservices
• mobile applications
• distributed systems
• authorization via third-party services

When Sessions are Better

• simple websites
• server-side rendering (SSR)
• when strict session control is needed
• when quick access revocation is important

The main takeaway: JWT is about flexibility and scalability, while sessions are about control and easy management.

Access Token and Refresh Token-How the Pair Works

In real applications, JWT is almost never used alone. Instead, a pair of tokens is used: access token and refresh token. This is needed for a balance between security and convenience.

Access Token

The main token used in requests. Its features:

• short lifespan (e.g., 5-30 minutes)
• sent with every request
• contains user data

If an access token is stolen, the attacker can use the system only for a limited time.

Refresh Token

An auxiliary token for renewal. Its features:

• lives longer (days or weeks)
• not used in regular requests
• stored more securely (usually in an HttpOnly cookie)

How This Works Together

1. User logs in
2. The server issues:
   • access token
   • refresh token
3. User makes requests with the access token
4. When the access token expires:
   • The client sends the refresh token to the server
   • The server verifies it
   • Issues a new access token
5. The user continues working without logging in again

Why Not Use Just One JWT?

• If the token is long-lived:
  • it's convenient
  • but if leaked, it's a serious threat
• If the token is short-lived:
  • it's secure
  • but inconvenient (frequent logouts)

The access + refresh token pair solves this problem:

• short token-for security
• long one-for convenience

Security Best Practice

The refresh token is often:

• stored in an HttpOnly cookie
• inaccessible via JavaScript
• protected from XSS attacks

This approach is used in almost all modern authorization systems.

JWT Token Security

JWT is considered a secure mechanism-but only if used correctly. Mistakes in implementation can lead to serious vulnerabilities.

Why JWT Can't Be Forged

The main protection of JWT is the signature. When the server creates the token:

• it signs it with a secret key
• the client doesn't know this key

On every request, the server:

• recalculates the signature
• compares it with the original

If data inside the token is changed, the signature won't match, and access will be denied.

The Main Risk-Token Theft

JWT can't simply be "guessed," but it can be stolen. If an attacker obtains a token, they can:

• send requests as the user
• access data

And the server won't be able to distinguish them from the real user.

Where to Store JWT Securely

There are several storage options, and they significantly affect security.

1. localStorage
   • easy to use
   • vulnerable to XSS attacks
2. sessionStorage
   • a bit safer
   • still accessible via JavaScript
3. HttpOnly cookie (best option)
   • not accessible to JavaScript
   • protected from XSS
   • can be used automatically by the browser

Common Beginner Mistakes

1. Token lifespan is too long
   If the token is valid for weeks, this is a risk.
2. Storing sensitive data
   Never put in JWT:
   • passwords
   • personal data
   • secret information
3. No HTTPS
   Transmitting tokens over HTTP is almost certain to cause a leak.
4. No revocation mechanism
   JWTs are hard to "cancel," so it's important to:
   • use a short lifespan
   • implement refresh tokens

Security Summary

JWT is secure if:

• HTTPS is used
• tokens have a short lifespan
• the access + refresh token pair is implemented
• the payload contains minimal data

When Should You Use JWT?

JWT is a powerful tool, but it's not suitable for every task. It's important to know where it truly offers advantages.

When JWT Is a Good Choice

1. SPA Applications (Single Page Application)
   In React, Vue, Angular apps:
   • frontend and backend are separated
   • many API requests
   • no traditional sessions
   JWT is ideal because:
   • does not require state storage
   • easy to pass with every request
2. Mobile Applications
   In iOS and Android apps:
   • no standard cookies like browsers
   • need a simple authorization mechanism
   JWT solves this:
   • stored on the device
   • sent with every request
3. APIs and Microservices
   In distributed systems:
   • many services
   • no single session server
   JWT allows:
   • no state storage
   • easy user verification on any service
4. Authorization via Third-party Services
   For example:
   • login via Google
   • login via social networks
   Such scenarios often use JWT in conjunction with OAuth (learn more in the article How OAuth 2.0 Works: Secure Login Without Passwords).

When JWT Is Not the Best Choice

1. Simple Websites
   If you have:
   • a small project
   • server-side rendering (SSR)
   Sessions will be simpler and more secure.
2. When Fast Access Revocation Is Needed
   It's hard to invalidate JWTs. If it's important to:
   • instantly log out users
   • control sessions
   it's better to use classic sessions.
3. High Security Requirements
   In some systems (banks, corporate services):
   • full control is required
   • management of each session is needed
   JWT may not be flexible enough.

Main Idea

JWT is a tool for:

• scalable systems
• APIs and frontend apps
• distributed architectures

But it is not a universal solution.

Conclusion

JWT token is a modern authorization method that works without storing sessions on the server. It contains all the necessary information within itself and is verified via a signature, making the system fast and scalable.

We discussed:

• what a JWT token is and how it works
• how authorization without sessions occurs
• how JWT differs from classic sessions
• how access and refresh tokens work
• the risks involved and how to avoid them

In practice, JWT is excellent for APIs, mobile apps, and microservices, but may be excessive for simple projects.

In short: JWT is about convenience and scale, while sessions are about control and simplicity.

The choice depends on your tasks, architecture, and security requirements.