Access token và refresh token hoạt động cùng nhau như thế nào?

Question

IT Interview Practice · Accepted Answer

Hai token đi theo một vòng đời đơn giản: **access token ngắn hạn** cấp quyền cho mỗi lời gọi API, và **refresh token dài hạn** âm thầm tạo access token mới khi chúng hết hạn — nhờ đó người dùng vẫn đăng nhập mà không cần nhập lại thông tin.

## Luồng hoạt động

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. gọi API: Authorization: Bearer <access>
     ▼
┌────────────┐  xác thực chữ ký + exp   (không tra DB)
│ Resource   │ ──── 200 OK ────▶ (access còn hạn)
│ API        │ ──── 401 ───────▶ (access hết hạn)
└────────────┘
     │  3. khi 401: POST /token { refresh }
     ▼
┌────────────┐  xác thực + xoay vòng
│ Auth server│ ──── access mới (+ refresh mới) ────▶ gọi lại
└────────────┘
```

1. **Login** — người dùng xác thực một lần; server trả về một **access token** (TTL ngắn) và một **refresh token** (TTL dài).
2. **Gọi API** — client gửi access token trong `Authorization: Bearer …` ở mọi request. API xác thực stateless (chữ ký + `exp`) rồi phản hồi — không cần kho session.
3. **Refresh khi hết hạn** — khi API trả `401` (hoặc client thấy `exp` sắp tới), client POST **refresh token** tới endpoint `/token` của server xác thực và nhận access token mới, rồi gọi lại request ban đầu. Người dùng không nhận ra gì.
4. **Logout / thu hồi** — server xóa hoặc đưa refresh token vào danh sách chặn; lần refresh kế thất bại và phiên kết thúc (access token hiện tại vẫn tự chết trong vài phút).

```js
// Interceptor phía client: refresh một lần khi 401, rồi gọi lại.
async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken(refreshToken); // POST /token
    res = await fetch(url, withAuth(opts, accessToken));   // gọi lại
  }
  return res;
}
```

## Xoay vòng refresh token (rotation)

Thực hành tốt nhất là **rotation**: mỗi lần refresh trả về một refresh token *mới* và vô hiệu cái cũ. Nếu một refresh token cũ (đã dùng) lại được xuất trình, đó là dấu hiệu bị trộm — server thu hồi toàn bộ họ token và bắt đăng nhập lại. Điều này giới hạn thiệt hại khi refresh token bị đánh cắp.

## Lưu trữ

- **Refresh token** → cookie `httpOnly`, `Secure`, `SameSite` để JavaScript (và do đó XSS) không đọc được.
- **Access token** → giữ trong bộ nhớ phía client; đời ngắn giới hạn phơi bày.
- Đừng đặt cái nào vào `localStorage` nếu tránh được — nó đọc được bởi bất kỳ script chèn vào nào.

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

Luồng này là xương sống của quản lý phiên trong SPA, app di động và API hiện đại, nên người phỏng vấn kỳ vọng bạn lần được nó từ đầu tới cuối: cấp cả hai lúc login, cấp quyền bằng access token, refresh trong suốt khi hết hạn, và xoay vòng + thu hồi để an toàn. Làm đúng chi tiết — xác thực stateless, refresh chỉ tại token endpoint, rotation kèm phát hiện dùng lại, và lưu trong `httpOnly` — là ranh giới giữa một phiên mượt và an toàn với một phiên mà chỉ một token bị trộm là chiếm được tài khoản lâu dài.

Luồng hoạt động

Xoay vòng refresh token (rotation)

Lưu trữ

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

Câu hỏi liên quan