JSON Web Token (JWT) hoạt động như thế nào?

Question

IT Interview Practice · Accepted Answer

**JSON Web Token (JWT)** là một token gọn, an toàn với URL, tự chứa, mang theo các claim về người dùng. Server ký nó một lần; sau đó có thể **xác thực** token ở mỗi request mà không cần tra cứu cơ sở dữ liệu — chính điều này khiến xác thực bằng JWT trở nên *stateless*.

## Cấu trúc: ba phần base64url

Một JWT là `header.payload.signature`, ba đoạn mã hóa base64url nối bằng dấu chấm:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — thuật toán ký, ví dụ `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — các **claim**: chuẩn như `sub` (subject/user id), `exp` (hết hạn), `iat` (thời điểm phát hành), `iss` (issuer), cùng các trường tùy biến (`role`, `email`).
- **Signature** — được tính trên header và payload bằng một secret hoặc private key.

> Payload được **mã hóa (encode), không phải mã hóa bảo mật (encrypt)**. Ai cũng có thể base64-decode để đọc, nên đừng bao giờ để mật khẩu hay bí mật trong JWT.

## Cách ký và xác thực hoạt động

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (đối xứng): cùng một secret để ký và xác thực. Đơn giản, nhưng mọi bên xác thực đều phải giữ secret.
- **RS256** (bất đối xứng): **private key** ký, **public key** xác thực. Server xác thực giữ private key; các service khác xác thực bằng public key và không bao giờ tự tạo được token.

Ở mỗi request, server tính lại signature trên header+payload nhận được rồi so sánh. Nếu khớp và `exp` còn ở tương lai, token được tin cậy — không cần kho lưu session.

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // ném lỗi nếu bị sửa hoặc hết hạn
  // claims.sub === "123"
} catch (e) {
  // từ chối: không hợp lệ hoặc đã hết hạn
}
```

## Phần khó: thu hồi (revocation)

Vì xác thực là stateless, bạn **không thể** vô hiệu hóa một token trước khi nó hết hạn chỉ bằng cách "xóa" ở phía server. Các cách giảm thiểu phổ biến:

- Giữ access token **ngắn hạn** (5–15 phút) và ghép với một **refresh token** dài hạn hơn.
- Duy trì một **danh sách chặn (denylist)** nhỏ chứa id token bị thu hồi (`jti`) cho đăng xuất/lộ token — điều này đưa một chút state trở lại.
- Xoay vòng khóa ký.

## Đánh đổi khi lưu trữ

| Nơi lưu | Ưu | Nhược |
|---|---|---|
| Cookie `httpOnly` | JS không đọc được (an toàn hơn với XSS) | Cần chống CSRF |
| `localStorage` | Đơn giản, không lo CSRF | Lộ ra với XSS |

## Tại sao điều này quan trọng

JWT cấp năng lượng cho xác thực stateless trên các API, microservice và SPA — một service có thể tin một request chỉ bằng cách xác thực chữ ký, không cần kho session chung. Nhưng chính tính stateless đó lại là cái bẫy phỏng vấn kinh điển: token khó thu hồi, payload đọc được, và nhầm lẫn `alg` hay thiếu kiểm tra hết hạn là những lỗ hổng thật sự. Biết chính xác chữ ký bảo vệ điều gì, và không bảo vệ điều gì, là nền tảng để dùng JWT an toàn.

Nơi lưu	Ưu	Nhược
Cookie `httpOnly`	JS không đọc được (an toàn hơn với XSS)	Cần chống CSRF
`localStorage`	Đơn giản, không lo CSRF	Lộ ra với XSS

Cấu trúc: ba phần base64url

Cách ký và xác thực hoạt động

Phần khó: thu hồi (revocation)

Đánh đổi khi lưu trữ

Tại sao điều này quan trọng

Câu hỏi liên quan