JWT Session 1: Why Modern ASP.NET Core Web APIs Use JWT Instead of Sessions

Modern applications are no longer limited to a single website. A business may have an Angular application, a mobile app, an admin dashboard, and third-party integrations—all using the same ASP.NET Core Web API.

Now imagine every request asking the server, "Who is this user?" and "Can this user access this resource?" If authentication is not designed properly, it can become difficult to manage as the application grows.

This is why many modern ASP.NET Core Web APIs use JWT (JSON Web Token) instead of traditional session-based authentication.

In this article, we'll understand what JWT authentication is, why it became popular, how it differs from sessions, and how it works at a high level. We won't generate tokens or write authentication code yet—that will come in the next articles.

What Is JWT Authentication?

JWT (JSON Web Token) is a token-based authentication mechanism used by APIs to identify users after they log in.

Instead of asking users to enter their username and password on every request, the API verifies the user's credentials once during login. If the credentials are valid, it creates a JWT and sends it back to the client.

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

Login
   ↓
API Validates User
   ↓
JWT Generated
   ↓
Client Stores JWT
   ↓
Client Sends JWT with Every Request

The API uses the token to identify the user before processing the request.

Why Do Modern APIs Prefer JWT?

To understand this, let's first look at how traditional session authentication works.

Suppose you build an online shopping application called SecureShop.

When a customer logs in, the server creates a session and stores information such as:

User ID
User Name
Login Status
User Role

The browser receives only a Session ID.

Every future request sends that Session ID, and the server looks up the corresponding session before processing the request.

Browser
   ↓
Session ID
   ↓
Server
   ↓
Session Storage
   ↓
User Information

This works well for many traditional web applications.

However, modern applications often have multiple clients:

Angular Web Application
Mobile Application
Admin Dashboard
Partner APIs

All of them communicate with the same ASP.NET Core Web API.

Instead of maintaining server-side session information for every client, JWT allows the client to carry a signed token that represents the authenticated user.

This makes authentication more flexible for API-based applications.

Sessions vs JWT

Both approaches solve the same problem—identifying authenticated users—but they do it differently.

Session Authentication	JWT Authentication
Server stores login information	Client stores the JWT
Client sends Session ID	Client sends JWT
Server looks up session	Server validates the token
Common in MVC applications	Common in REST APIs
Requires session management	Uses token-based authentication

Neither approach is universally better.

If you're building a traditional ASP.NET Core MVC application, sessions may still be an excellent choice.

If you're building APIs consumed by different applications, JWT is often a better fit.

How Does JWT Authentication Work?

At a high level, the process is straightforward.

Step 1: User Logs In

The user submits login credentials.

POST /api/auth/login

{
  "email": "[email protected]",
  "password": "Password@123"
}

Step 2: API Validates Credentials

The API checks whether the email and password are correct.

If they are invalid, the login request is rejected.

If they are valid, the API continues to the next step.

Step 3: API Generates a JWT

Instead of creating a server-side session, the API generates a JWT.

The token represents the authenticated user.

The client receives something similar to this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Don't worry about what this token contains yet.

We'll completely break it down in the next article.

Step 4: Client Stores the Token

The application stores the JWT after a successful login.

From this point onward, the user does not need to log in before every request.

Step 5: Client Sends the JWT

Whenever the client calls a protected API, it sends the token using the HTTP Authorization header.

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

The word Bearer simply means that the client is presenting this token as proof of authentication.

Internal Authentication Flow

The entire authentication process looks like this.

User
   │
   │ Login
   ▼
ASP.NET Core Web API
   │
   │ Validate Credentials
   ▼
Generate JWT
   │
   │ Return Token
   ▼
Client
   │
   │ Bearer Token
   ▼
Protected API
   │
   │ Validate Token
   ▼
Process Request

Notice something important.

The user's password is sent only during login.

Every protected request afterward uses the JWT instead of the password.

This reduces unnecessary credential transmission and provides a standard way for APIs to identify users.

Practical Example

Let's continue with our SecureShop API.

The application contains three protected endpoints.

GET /api/products

GET /api/orders

GET /api/profile

A customer first logs in.

POST /api/auth/login

After successful authentication, the API returns a JWT.

Now the customer requests their profile.

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

Before executing the request, the API validates the token.

If the token is valid, the request continues.

If the token is missing or invalid, the API rejects the request.

This simple flow allows the same API to work with:

Angular applications
React applications
Mobile apps
Desktop applications
Third-party clients

All clients authenticate in exactly the same way.

Why Is JWT Popular for APIs?

JWT became popular because it fits naturally into modern API architecture.

Some practical benefits include:

It works well with different client applications.
It avoids server-side session dependency for every request.
It is suitable for distributed applications running on multiple servers.
It provides a standard authentication mechanism supported by ASP.NET Core.
It works well with cloud-native and microservice-based applications.

These advantages make JWT a common choice for RESTful Web APIs.

Common Mistakes

When developers first start learning JWT, they often make a few common assumptions.

Mistake 1: Thinking JWT Is Encrypted

A JWT is usually encoded and digitally signed, not encrypted.

Its contents can often be viewed by anyone who has the token.

Because of this, never store sensitive information such as:

Passwords
OTPs
Credit card numbers
Database credentials

Only include the information required for authentication and authorization.

Mistake 2: Assuming JWT Replaces Security

JWT is only an authentication mechanism.

Applications still need:

HTTPS
Secure password storage
Proper authorization
Token expiration
Secure token storage

JWT is one part of application security, not the entire security solution.

Mistake 3: Believing Sessions Are Obsolete

Many beginners think sessions are "old" and JWT is always the better option.

That's not true.

Session authentication is still widely used and works very well for traditional server-rendered applications.

Choose the authentication approach based on your application's architecture—not on popularity.

Key Takeaways

JWT is a token-based authentication mechanism commonly used by ASP.NET Core Web APIs.
Users authenticate only once using their credentials.
After successful login, the API generates a JWT.
The client sends the JWT with every protected request.
The API validates the token before processing the request.
JWT is especially useful when multiple applications consume the same API.
Sessions and JWT both solve authentication problems, but they use different approaches.
Choosing between them depends on the application's requirements.

In the next article, we'll open a JWT and understand what is actually inside it. You'll learn how the Header, Payload, and Signature work together, and why a JWT can detect if someone tries to modify its contents.