Session-based Authentication — cơ chế chi tiết

Đây là cơ chế đơn giản nhất và cũng là nền tảng để hiểu mọi cơ chế phức tạp hơn sau này.

1. Đăng nhập: client gửi username/password lên server (qua HTTPS).
2. Server tạo session: nếu thông tin đúng, server sinh ra một session ID ngẫu nhiên (không đoán được), lưu session này ở phía server — có thể là bộ nhớ, database, hoặc phổ biến nhất là Redis. Session lưu những gì cần thiết: user id, thời điểm đăng nhập, quyền hạn...
3. Server trả cookie: response trả về kèm header Set-Cookie, ví dụ:

   Set-Cookie: session_id=a1b2c3d4e5; HttpOnly; Secure; SameSite=Strict; Max-Age=3600

   Trình duyệt tự động lưu cookie này và tự động đính kèm vào mọi request tiếp theo gửi tới cùng domain — client không cần code gì thêm.
4. Các request tiếp theo: trình duyệt tự gửi kèm header Cookie: session_id=a1b2c3d4e5. Server nhận được, tra cứu session ID này trong session store. Nếu tìm thấy và còn hạn → xác định được user, cấp quyền truy cập; nếu không tìm thấy hoặc hết hạn → từ chối, yêu cầu đăng nhập lại.
5. Đăng xuất: server xoá session tương ứng khỏi session store. Từ thời điểm đó, session ID cũ (dù client vẫn còn giữ cookie) không còn tra cứu ra kết quả nào — đây chính là lý do session thu hồi (revoke) được ngay lập tức, khác biệt lớn nhất so với JWT.

Ba thuộc tính (attribute) quan trọng của cookie, quyết định phần lớn mức độ an toàn:

Thuộc tính	Ý nghĩa
HttpOnly	JavaScript trên trang không đọc được cookie này — chặn việc mã độc XSS ăn cắp session ID
Secure	Cookie chỉ được gửi qua kết nối HTTPS, không gửi qua HTTP thường
SameSite	Kiểm soát cookie có được gửi kèm trong request xuất phát từ domain khác hay không — xem chi tiết ở trang CSRF & SameSite

Vì server phải "nhớ" mọi session đang hoạt động, khi hệ thống có nhiều server thì các server phải đọc chung một session store (Redis) — nếu không, request rơi vào server không giữ session đó sẽ báo lỗi chưa đăng nhập dù thực tế đã đăng nhập.