Authentication (xác thực): xác minh "bạn là ai" — đăng nhập bằng email/password, xác thực thành công thì biết được danh tính user. Authorization (phân quyền): xác định "bạn được làm gì" — sau khi biết danh tính, hệ thống kiểm tra user đó có quyền truy cập resource/hành động cụ thể hay không. Nhầm lẫn 2 khái niệm này khi trả lời là dấu hiệu thiếu kinh nghiệm thực chiến.
"JWT gồm những phần nào?" — 3 phần ngăn cách bởi dấu chấm: Header (thuật toán mã hoá), Payload (dữ liệu, vd. userId, thời gian hết hạn), Signature (chữ ký để xác minh token không bị giả mạo — KHÔNG mã hoá payload, chỉ ký để chống sửa đổi).
"JWT có thể bị đọc nội dung không? Có nên lưu thông tin nhạy cảm trong đó không?" — Payload chỉ encode Base64, KHÔNG mã hoá — ai cũng đọc được nội dung nếu có token, chỉ không sửa được vì có chữ ký xác minh. Vì vậy tuyệt đối không lưu password hay thông tin nhạy cảm trong JWT payload.
"Làm sao revoke (thu hồi) 1 JWT trước khi hết hạn?" — Đây là điểm yếu cố hữu của JWT (stateless — server không lưu trạng thái token nào còn hiệu lực) — giải pháp: dùng blacklist (lưu token đã revoke, kiểm tra mỗi request — nhưng làm mất bớt lợi ích stateless), hoặc dùng thời gian hết hạn ngắn (access token) kết hợp refresh token có thể revoke được ở database.
"OAuth 2.0 giải quyết vấn đề gì?" — Cho phép ứng dụng bên thứ 3 truy cập tài nguyên của user (vd. thông tin Google) mà KHÔNG cần user chia sẻ password trực tiếp cho ứng dụng đó — user cấp quyền (authorize) qua nhà cung cấp gốc (Google, Facebook...), ứng dụng nhận access token có phạm vi quyền hạn giới hạn.
"Authorization Code flow khác Implicit flow thế nào?" — Authorization Code flow (khuyến nghị cho web app có backend) trao đổi code lấy token qua backend, an toàn hơn vì token không lộ ra trình duyệt. Implicit flow (cũ, dành cho SPA không có backend) trả token trực tiếp qua URL — dễ bị lộ hơn, hiện không còn khuyến nghị, thay bằng Authorization Code + PKCE.
"Lưu JWT ở đâu tại client — localStorage hay cookie?" — localStorage dễ bị đánh cắp qua XSS (bất kỳ script nào chạy trên trang đều đọc được). httpOnly cookie an toàn hơn trước XSS (JavaScript không đọc được) nhưng cần phòng CSRF riêng (dùng CSRF token hoặc SameSite cookie attribute). Không có lựa chọn "hoàn hảo tuyệt đối" — cần hiểu đánh đổi để chọn đúng theo bối cảnh ứng dụng.
Nếu từng tự implement authentication, kể rõ quyết định: access token/refresh token có thời hạn bao lâu và lý do, lưu ở đâu và cách phòng chống tấn công tương ứng — thể hiện bạn hiểu đánh đổi bảo mật, không chỉ copy code mẫu.