Bảo mật REST API thế nào (xác thực, phân quyền, kênh truyền)?

Question

IT Interview Practice · Accepted Answer

Bảo mật REST API nghĩa là trả lời ba câu hỏi trên mỗi request: **bạn là ai** (authentication), **bạn được làm gì** (authorization), và **kênh truyền có riêng tư không** (transport). Vì REST **stateless**, credential phải đi cùng mỗi request chứ không nằm trong session server.

## Kênh truyền: luôn HTTPS

Mọi thứ dưới đây giả định có **TLS/HTTPS**. Không có nó, token và API key đi ở dạng plaintext và bị nghe lén. Đây là điều không thể thoả hiệp — một bearer token qua HTTP là một token đã lộ.

## Các lựa chọn xác thực

**API key** — một bí mật tĩnh trong header. Đơn giản; hợp cho server-to-server và định danh một *ứng dụng*, không phải user. Bản thân yếu (không hết hạn, không scope) trừ khi ghép thêm.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — chuẩn cho truy cập **uỷ quyền** ("cho App X đọc dữ liệu của tôi mà không cần mật khẩu"). App lấy một **access token** qua một flow (vd. Authorization Code) và gửi như bearer token. Đây là cách "Sign in with Google" và tích hợp bên thứ ba hoạt động.

**JWT (JSON Web Token)** — một *định dạng* token phổ biến: token tự chứa, có chữ ký, mang các claim (user id, role, hạn dùng). Server xác minh chữ ký — không cần tra database, hợp với REST stateless.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Phân quyền: scope và role

Authentication chứng minh danh tính; **authorization** quyết định quyền truy cập. Token mang **scope** (`orders:read`, `orders:write`) hoặc role; server kiểm tra theo từng endpoint và trả `403 Forbidden` khi không đủ (khác `401` cho thiếu/sai auth).

```text
Không có/token sai        → 401 Unauthorized
Token hợp lệ, thiếu scope → 403 Forbidden
```

## Những điều thiết yếu khác

```text
✓ Access token ngắn hạn + refresh token (giảm thiệt hại nếu lộ)
✓ Rate limiting (429) để chặn brute-force và lạm dụng
✓ Validate/sanitize mọi input; không bao giờ tin client
✓ Nguyên tắc least privilege trên scope
```

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

Bảo mật là nơi một lỗi nhỏ thành một vụ rò rỉ, nên người phỏng vấn dùng câu này để xem bạn tư duy về nó một cách có cấu trúc hay chỉ đọc buzzword. Tín hiệu họ tìm là bạn **tách ba tầng** — transport (HTTPS, luôn luôn), authentication (chứng minh danh tính, stateless, qua bearer token/JWT/OAuth), và authorization (scope và least privilege) — và không lẫn lộn chúng, vd. dùng đúng `401` cho "chưa xác thực" so với `403` cho "đã xác thực nhưng không được phép". Câu trả lời mạnh cho thấy hiểu các đánh đổi thực tế: JWT tiện và stateless nhưng khó thu hồi trước khi hết hạn (nên dùng vòng đời ngắn cộng refresh token), API key định danh app không phải user, và OAuth tồn tại chính để user không phải giao mật khẩu cho bên thứ ba. Gắn với tính stateless của REST — credential trên mỗi request, không session server — cho thấy bạn hiểu *vì sao* bảo mật API có hình dạng như vậy.

Kênh truyền: luôn HTTPS

Các lựa chọn xác thực

Phân quyền: scope và role

Những điều thiết yếu khác

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

Câu hỏi liên quan