Hai token tồn tại để giải một xung đột trực tiếp: access token phải được gửi ở mọi request (nên bị phơi bày rất nhiều), nhưng bạn cũng muốn phiên đăng nhập kéo dài lâu mà không bắt đăng nhập lại thường xuyên. Không thể có cả hai một cách an toàn trong một token duy nhất — nên ta tách vai trò ra.
Authorization ở mọi lời gọi API. Vì được truyền liên tục, khả năng rò rỉ cao; giữ nó ngắn nghĩa là token bị đánh cắp gần như hết hạn ngay.Login ──▶ access (15m) + refresh (30d)
Mọi lời gọi API ──▶ gửi access
Access hết hạn ──▶ gửi refresh ──▶ access mới (+ refresh xoay vòng)
| Một access token dài hạn | Access + refresh | |
|---|---|---|
| Phơi bày | Gửi mọi request, sống lâu → cửa sổ trộm lớn | Access ngắn hạn; refresh ít gửi |
| Thu hồi | Khó (JWT stateless không thể hủy cấp) | Thu hồi refresh; access chết trong vài phút |
| UX | Đăng nhập lại thường xuyên nếu ngắn | Duy trì đăng nhập không cần nhập lại thông tin |
| Bán kính thiệt hại khi rò rỉ | Lớn | Nhỏ (access hết hạn nhanh) |
httpOnly, ngoài tầm với của XSS.Đây là thiết kế xác thực hiện đại chuẩn mực, và người phỏng vấn hỏi để xem bạn có hiểu cái vì sao, không chỉ cái như thế nào. Điểm mấu chốt là đánh đổi: tính stateless và phơi bày ngắn (access) đối lại phiên dài và khả năng thu hồi (refresh). Làm sai — access token dài hạn, không xoay vòng, refresh lưu trong localStorage — biến một token rò rỉ thành việc chiếm tài khoản lâu dài. Gọi tên được cách tách và mỗi token đem lại gì chính là điều một kỹ sư có ý thức bảo mật được kỳ vọng phải biết.
Thư viện câu hỏi phỏng vấn IT với đáp án chi tiết — từ Junior đến Senior.
Ủng hộ