---
title: "How does token-based authentication work?"  
description: "How does token-based authentication work?"  
author: "ICSM Computer"  
published: 2025-06-05  
updated: 2025-06-05  
canonical: https://www.mindstick.com/interview/34211/how-does-token-based-authentication-work  
category: "api(s)"  
tags: ["c#", "api(s)", "authentication", "authorization"]  
reading_time: 4 minutes  

---

# How does token-based authentication work?

**Token-based authentication** is a stateless, scalable way to manage user sessions in APIs and web apps. Here’s how it works, step by step:

### Overview of the Flow

#### 1. User Logs In

The user sends their credentials (e.g., username and password) to the authentication server via a `POST` request.

```plaintext
POST /api/login
{
  "username": "john",
  "password": "secret"
}
```

#### 2. Server Validates Credentials

If valid, the server generates a **token** (often a **JWT**) that contains encoded user info (like `userId`, `roles`, expiration time).

#### 3. Token is Sent to the Client

The server returns the token in the response:

```plaintext
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
```

#### 4. Client Stores the Token

- The client (browser, mobile app, etc.) stores it in:
- Browser: `localStorage` / `sessionStorage`
- Mobile: Secure storage

#### 5. Client Sends Token with Each Request

For every request to protected resources, the client includes the token in the `Authorization` header:

```plaintext
GET /api/user/profile
Authorization: Bearer eyJhbGciOi...
```

#### 6. Server Verifies Token

- The server **verifies** the token (checks signature, expiration, etc.).
- If valid, the request proceeds.
- If invalid or expired, return `401 Unauthorized`.

#### 7. No Server-Side Session

The server **does not store session state** — all info is in the token itself. This makes it **stateless** and scalable.

### Common Token Types

| Type | Description |
| --- | --- |
| **JWT (JSON Web Token)** | Self-contained token with claims (user info, expiry, etc.). |
| **Opaque Token** | Random string, requires DB lookup to validate. |

### Benefits

- Stateless: no need to store session on the server.
- Scalable: great for distributed/microservice architectures.
- Secure (if HTTPS and token handling is done right).
- Supports expiration, revocation (with some trade-offs).

### Common Security Best Practices

- Always use HTTPS.
- Set short expiration + refresh tokens (OAuth2-style).
- Store tokens securely (not in `localStorage` if XSS is a risk).
- Use proper token revocation strategy (e.g., blacklist).

## Answers

### Answer by ICSM Computer

**Token-based authentication** is a stateless, scalable way to manage user sessions in APIs and web apps. Here’s how it works, step by step:

### Overview of the Flow

#### 1. User Logs In

The user sends their credentials (e.g., username and password) to the authentication server via a `POST` request.

```plaintext
POST /api/login
{
  "username": "john",
  "password": "secret"
}
```

#### 2. Server Validates Credentials

If valid, the server generates a **token** (often a **JWT**) that contains encoded user info (like `userId`, `roles`, expiration time).

#### 3. Token is Sent to the Client

The server returns the token in the response:

```plaintext
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
```

#### 4. Client Stores the Token

- The client (browser, mobile app, etc.) stores it in:
- Browser: `localStorage` / `sessionStorage`
- Mobile: Secure storage

#### 5. Client Sends Token with Each Request

For every request to protected resources, the client includes the token in the `Authorization` header:

```plaintext
GET /api/user/profile
Authorization: Bearer eyJhbGciOi...
```

#### 6. Server Verifies Token

- The server **verifies** the token (checks signature, expiration, etc.).
- If valid, the request proceeds.
- If invalid or expired, return `401 Unauthorized`.

#### 7. No Server-Side Session

The server **does not store session state** — all info is in the token itself. This makes it **stateless** and scalable.

### Common Token Types

| Type | Description |
| --- | --- |
| **JWT (JSON Web Token)** | Self-contained token with claims (user info, expiry, etc.). |
| **Opaque Token** | Random string, requires DB lookup to validate. |

### Benefits

- Stateless: no need to store session on the server.
- Scalable: great for distributed/microservice architectures.
- Secure (if HTTPS and token handling is done right).
- Supports expiration, revocation (with some trade-offs).

### Common Security Best Practices

- Always use HTTPS.
- Set short expiration + refresh tokens (OAuth2-style).
- Store tokens securely (not in `localStorage` if XSS is a risk).
- Use proper token revocation strategy (e.g., blacklist).


---

Original Source: https://www.mindstick.com/interview/34211/how-does-token-based-authentication-work

Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.