Cách đây chục năm, khi làm web, mọi thứ khá đơn giản: Client gọi lên, Server kiểm tra đăng nhập, rồi Server lưu thông tin ông khách đó vào một cuốn sổ (Session) trong bộ nhớ (RAM). Mỗi lần ông khách quay lại, Server lại lục cuốn sổ ra soi: “À, ông này nãy vào rồi, cho qua”.

Đó là thời của Session-based Authentication. Nó ngon, bổ, nhưng… không còn rẻ nữa khi chúng ta bước vào kỷ nguyên của Microservices, của Mobile App, và những hệ thống phục vụ cả triệu người cùng lúc.

Khi đó, cuốn sổ của Server bị quá tải. Server bắt đầu “thở oxy”. Và người ta cần một giải pháp mới. Đó là lúc JWT (JSON Web Token) bước ra ánh sáng.

1. Sự khác biệt: Chiếc danh sách khách mời vs. Chiếc vòng tay sự kiện

Để dễ hình dung nhất về sự khác biệt giữa cách làm cũ (Session) và cách làm mới (JWT), hãy tưởng tượng bạn đi tham dự một lễ hội âm nhạc.

Cách cũ (Session-based): Tại cổng soát vé, có một anh bảo vệ cầm một danh sách khách mời thật dài (Database/Memory).

• Bạn đến, khai tên.
• Anh bảo vệ dò danh sách từ trên xuống dưới.
• Thấy tên bạn -> Cho vào.
• Bạn đi ra mua nước rồi quay lại cổng -> Anh bảo vệ lại phải dò danh sách lần nữa.
• Vấn đề: Nếu lễ hội có 10 cổng, các anh bảo vệ phải gọi điện cho nhau liên tục để đồng bộ danh sách. Nếu danh sách có 1 triệu người, anh bảo vệ dò toét mắt.

Cách mới (Token-based / JWT): Tại cổng soát vé, anh bảo vệ không giữ danh sách nào cả.

• Bạn đến, khai tên lần đầu. Anh bảo vệ xác nhận đúng là bạn.
• Anh ta đóng một cái dấu mộc (hoặc đeo vòng tay) cho bạn. Trên đó ghi rõ: “Vào được khu VIP, hết hạn lúc 10h tối”.
• Lần sau bạn quay lại, anh bảo vệ chỉ cần nhìn cái vòng tay.
• Vòng tay thật? Còn hạn? -> Cho vào. Không cần tra danh sách, không cần hỏi ai cả.

-> Cái vòng tay đó chính là JWT.

2. Tại sao chúng ta cần JWT? (Tại sao nó lại “Vibe” đến thế?)

Trong thế giới lập trình hiện đại, JWT giải quyết được những nỗi đau đầu trần ai của Session:

a. Server được “tự do” (Stateless)

Đây là điểm ăn tiền nhất. Server không cần lưu trạng thái của user nữa. Server không cần tốn RAM để nhớ xem ông A, ông B đang đăng nhập hay chưa. Mọi thông tin cần thiết đã nằm gói gọn trong cái Token mà user tự cầm (Client side). Server chỉ việc xác minh chữ ký (verify signature) là xong. Server nhẹ gánh, chạy nhanh hơn hẳn.

b. Dễ dàng mở rộng (Scalability)

Giả sử ứng dụng của bạn nổi tiếng quá, bạn phải chạy trên 10 con Server (Load Balancing).

• Với Session: Nếu user đăng nhập ở Server 1 (lưu session ở Server 1), lần sau request chạy vào Server 2 -> Server 2 ngơ ngác “Ủa ông là ai?”. Bạn lại phải cấu hình Sticky Session hoặc dùng Redis để share session phức tạp.
• Với JWT: User cầm Token chạy vào Server nào cũng được. Vì Server nào cũng có chung công thức để giải mã cái Token đó. Đơn giản, hiệu quả.

c. Bạn của mọi nhà (Mobile & Cross-domain)

Cookies (nơi thường lưu Session ID) làm việc rất tốt trên trình duyệt web, nhưng lại khá “củ chuối” trên Mobile App (iOS/Android) hoặc khi bạn muốn gọi API từ một domain khác (CORS). JWT là một chuỗi ký tự đơn thuần, bạn nhét vào Header của request HTTP (Authorization: Bearer...). App nào cũng gửi được, domain nào cũng chơi được.

3. Có phải JWT là “chìa khóa vạn năng”?

Nghe thì hoàn hảo, nhưng JWT cũng có những điểm yếu chết người nếu dùng sai cách (ví dụ như việc không thể thu hồi token tức thì – sẽ bàn kỹ hơn ở các phần sau).

Tuy nhiên, không thể phủ nhận JWT đã trở thành tiêu chuẩn của ngành công nghiệp (Industry Standard) cho các hệ thống RESTful API hiện đại.

Tạm kết

Vậy là chúng ta đã hiểu JWT là gì (là cái vé vào cửa tự chứa thông tin) và Tại sao nên dùng nó (để giải phóng Server).

Nhưng cái “vé” này trông như thế nào? Làm sao để đảm bảo người dùng không tự in vé giả ở nhà rồi mang đến lừa Server? Bí mật nằm ở cấu tạo 3 phần của nó: Header, Payload và Signature.