Bài viết này sẽ giúp bạn so sánh session vs JWT một cách chi tiết để tìm ra giải pháp phù hợp nhất cho dự án của mình.

1. Session-based Authentication là gì trong bài toán session vs JWT?

Cơ chế vận hành (Flow)

Với phương thức này, trạng thái đăng nhập của người dùng được quản lý trực tiếp và tập trung tại máy chủ (Server-side). Quy trình diễn ra như sau:

1. Đăng nhập: Người dùng gửi thông tin username/password lên server.
2. Khởi tạo: Server xác thực thông tin, tạo ra một phiên làm việc (session) và lưu trữ nó vào bộ nhớ (Memory), Redis hoặc Cơ sở dữ liệu (DB).
3. Phản hồi: Server gửi lại cho trình duyệt một session id, thường được lưu trữ trong một Cookie.
4. Xác thực Request: Với mọi request tiếp theo, trình duyệt tự động gửi kèm cookie chứa session id này.
5. Kiểm tra: Server dùng session id nhận được để tra cứu lại trạng thái trong kho lưu trữ nhằm nhận diện người dùng và quyền hạn của họ.

Nói một cách đơn giản: Trạng thái đăng nhập được “gửi gắm” hoàn toàn cho server giữ hộ. Ví dụ, khi trình duyệt gửi session_id=abc123, server sẽ lookup mã này để biết đó là User A với vai trò Admin.

Ưu điểm nổi bật

• Dễ triển khai: Đây là mô hình truyền thống, hầu hết các framework web (như Django, Laravel, Express) đều hỗ trợ tận răng.
• Kiểm soát tuyệt đối (Revoke): Server có toàn quyền quyết định một phiên làm việc có được tiếp tục hay không. Nếu muốn logout người dùng hoặc khóa tài khoản ngay lập tức, bạn chỉ cần xóa session trong DB/Redis.

Những “gót chân Achilles”

• Tính Stateful: Server phải tốn tài nguyên để lưu trữ trạng thái của tất cả người dùng đang đăng nhập.
• Khó mở rộng ngang (Horizontal Scaling): Khi hệ thống lớn mạnh và cần nhiều server, bạn buộc phải dùng một kho lưu trữ tập trung (như Redis) để tất cả các server đều có thể truy cập chung dữ liệu session.
• Không thân thiện với hệ sinh thái hiện đại: Session-based auth thường gây khó khăn khi làm việc với Mobile App, hệ thống Microservices hoặc các API công khai (Public API) do phụ thuộc vào cơ chế Cookie và sự ràng buộc chặt chẽ với server ban đầu.

2. Token-based Authentication: Lựa Chọn Của Kỷ Nguyên Microservices

Cơ chế vận hành (Flow)

Khác với sự phụ thuộc vào server của session, Token-based Authentication chuyển trọng tâm quản lý trạng thái về phía Client (Stateless).

1. Đăng nhập: Người dùng đăng nhập thành công.
2. Tạo Token: Server tạo ra một chuỗi mã hóa (thường là JWT – JSON Web Token) chứa các thông tin cần thiết như user id, claims (quyền hạn), thời gian hết hạn….
3. Phân phối: Server trả token này về cho client.
4. Lưu trữ & Gửi đi: Client lưu token (trong LocalStorage hoặc Cookie). Mỗi request sau đó, client gửi token kèm theo trong Header (thường là Authorization: Bearer <token>).
5. Xác thực: Server nhận token và chỉ cần thực hiện việc Verify (kiểm tra chữ ký, thời hạn, các thông tin đính kèm) mà không cần phải lục tìm trong database.

Ưu điểm vượt trội

• Tính Stateless: Server không cần lưu trữ bất kỳ thông tin phiên làm việc nào. Điều này giúp tiết kiệm tài nguyên và cực kỳ dễ dàng khi cần mở rộng hệ thống (scale ngang).
• Sẵn sàng cho Microservices: Trong hệ thống phân tán, các service khác nhau có thể tự xác thực token mà không cần gọi ngược về service đăng nhập ban đầu.
• Đa nền tảng: Hoạt động hoàn hảo trên cả Web, Mobile App và các thiết bị IoT. Đây cũng là tiêu chuẩn cho các hệ thống Single Sign-On (SSO).

Những thách thức cần đối mặt

• Khó thu hồi (Revoke): Vì server không lưu trạng thái, việc vô hiệu hóa một token còn hạn là rất phức tạp. Bạn thường phải chờ token tự hết hạn hoặc triển khai các giải pháp như “Blacklist” trong Redis.
• Kích thước dữ liệu: Một JWT chứa nhiều thông tin (claims) có thể lớn hơn nhiều so với một session id ngắn gọn, làm tăng dung lượng mỗi request.
• Bảo mật: Nếu token bị đánh cắp, kẻ xấu có thể sử dụng nó cho đến khi hết hạn. Do đó, việc thiết kế thời gian hết hạn (expire time) và cơ chế làm mới (refresh token) cần được tính toán cực kỳ cẩn thận.

3. So Sánh Chi Tiết: Đặt Lên Bàn Cân

Để có cái nhìn tổng quan nhất, hãy cùng xem bảng so sánh dưới đây dựa trên các tiêu chí kỹ thuật trọng yếu:

4. Xác Thực Kiểu Nào Là “Đúng” Cho Hệ Thống Của Bạn?

Lựa chọn giữa Session và Token không phải là tìm ra cái nào tốt hơn, mà là tìm ra cái nào phù hợp hơn với bài toán hiện tại.

Khi nào nên chọn Session-based Auth?

Bạn nên ưu tiên phương pháp này nếu:

• Đang xây dựng một website kiểu Monolith (như WordPress, một ứng dụng CRUD đơn giản).
• Yêu cầu bảo mật đòi hỏi khả năng ngắt kết nối người dùng ngay lập tức (như ứng dụng ngân hàng, tài chính).
• Hệ thống chỉ phục vụ trình duyệt web và không có ý định mở rộng sang ứng dụng di động trong tương lai gần.

Khi nào nên chọn Token-based Auth?

Đây là lựa chọn “vàng” nếu:

• Hệ thống được thiết kế theo kiến trúc Microservices hoặc Distributed.
• Bạn cần phục vụ đồng thời cả ứng dụng Web và Mobile App.
• Cần triển khai tính năng Single Sign-On (SSO) để người dùng đăng nhập một lần cho nhiều hệ thống con.
• Dự án đòi hỏi khả năng mở rộng cực lớn với hàng triệu người dùng đồng thời.

Kết luận

Việc lựa chọn giữa Session-based Auth và Token-based Auth là một quyết định chiến lược ảnh hưởng lâu dài đến hiệu suất và khả năng bảo mật của hệ thống. Trong khi Session mang lại sự kiểm soát chặt chẽ, thì Token lại mở ra cánh cửa của sự linh hoạt và khả năng mở rộng không giới hạn.

Hy vọng bài viết này đã giúp bạn giải mã được những thắc mắc về hai phương thức xác thực phổ biến này. Hãy nhớ rằng: không có công cụ nào là vạn năng, chỉ có công cụ được sử dụng đúng mục đích!

Bài viết Session vs JWT: So Sánh Authentication Cho API đã xuất hiện đầu tiên vào ngày Movaŋ ISO is the Platform that makes Digital Transformation Agile for organizations.

Giới thiệu về REST API

REST API là gì?

REST (REpresentational State Transfer) được đưa ra vào năm 2000, trong luận văn tiến sĩ của Roy Thomas Fielding (đồng sáng lập giao thức HTTP). Nó là một dạng chuyển đổi cấu trúc dữ liệu, là một phong cách kiến ​​trúc cho việc thiết kế các ứng dụng có kết nối. Nó sử dụng HTTP đơn giản để tạo cho giao tiếp giữa các máy. Vì vậy, thay vì sử dụng một URL cho việc xử lý một số thông tin người dùng, REST gửi một yêu cầu HTTP như GET, POST, DELETE, vv đến một URL để xử lý dữ liệu.

API (Application Programming Interface) là giao diện lập trình ứng dụng giúp tạo ra các phương thức kết nối với các thư viện và ứng dụng khác nhau.

REST API là một ứng dụng chuyển đổi cấu trúc dữ liệu có các phương thức để kết nối với các thư viện và ứng dụng khác. REST API không được xem là một công nghệ, nó là một giải pháp để tạo ra các ứng dụng web services thay thế cho các kiểu khác như SOAP, WSDL (Web Service Definition Language),…

Ràng buộc REST

• Hệ thống hoạt động theo mô hình client-server, trong đó server là tập hợp các service nhỏ lắng nghe các request từ client. Với từng request khác nhau thì có thể một hoặc nhiều service xử lý.
• Stateless (phi trạng thái). Đơn giản server và client không lưu trạng thái của nhau -> mỗi request lên server thì client phải đóng gói thông tin đầy đủ để thằng server hiểu được. Điều này giúp hệ thống của bạn dễ phát triển,bảo trì, mở rộng vì không cần tốn công CRUD trạng thái của client . Hệ thống phát triển theo hướng này có ưu điểm nhưng cũng có khuyết điểm là gia tăng lượng thông tin cần truyền tải giữa client và server.
• Khả năng caching : Các response có thể lấy ra từ cache. Bằng cách cache các response , server giảm tải việc xử lý request, còn client cũng nhận được thông tin nhanh hơn. Ở đây ta đặt 1 thằng cache vào giữa : client- cache- server.
• Chuẩn hóa các interface : Đây là một trong những đặc tính quan trọng của hệ thống REST. Bằng cách tạo ra các quy ước chuẩn để giao tiếp giữa các thành phần trong hệ thống, đơn giản hóa việc client có thể tương tác với server. Các quy ước này áp dụng cho toàn bộ các service giúp cho người sử dụng hệ thống của bạn dễ dụng hơn. Dễ hiểu hơn trên hệ thống đặt ra 1 chuẩn API để người dùng dù là mobile, web đều có thể kết nối vào được. Hệ thống REST có yếu điểm ở đây vì khi chuẩn hóa rồi ta không thế tối ưu từng kết nối.
• Phân lớp hệ thống : trong hệ thống REST chia tách các thành phần hệ thống theo từng lớp, mỗi lớp chỉ sử dụng lớp ở dưới nó và giao tiếp với lớp ở ngay trên nó mà thôi. Điều này giúp giảm độ phức tạp của hệ thống, giúp các thành phần tách biệt nhau từ đó dễ dàng mở rộng từng thành phần.

Các ưu điểm của REST

• Giúp cho ứng dụng trở nên rõ ràng hơn.
• REST URL đại diện cho resource chứ không phải là hành động.
• Dữ liệu được trả về với nhiều định dạng khác nhau như:  xml, html, rss, json …
• Code đơn giản và ngắn gọn.
• REST chú trọng vào tài nguyên hệ thống.

Các trang web ngày nay thường sử dụng REST API để cho phép kết nối dữ liệu của họ.

Facebook cũng cung cấp các REST API giúp các ứng dụng bên ngoài có thể kết nối đến dữ liệu của họ. (bạn có thể tham khảo tại đường dẫn: https://developers.facebook.com/tools/explorer).

Nếu thiết kế web service trước kia từng là SOAP, WSDL … Thì hiện nay đã có một phương pháp tốt hơn đó là: REST (Representation State Stranfer). Bởi vì REST là một phương thức nhỏ gọn . Nên rất được ưa chuộng cho dữ liệu HTTP.

Xem thêm: Phân biệt RestAPI và GraphAPI

Bài viết REST API là gì? Giới thiệu về REST API. đã xuất hiện đầu tiên vào ngày Movaŋ ISO is the Platform that makes Digital Transformation Agile for organizations.