Cookies hay Bearer Tokens: Bài học xương máu từ một quyết định thiết kế xác thực sai lầm

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Bearer tokens yêu cầu gửi thủ công qua header, trong khi cookies được trình duyệt tự động đính kèm.
• Cookies dễ bị tấn công CSRF, còn Bearer tokens lưu trữ tại localStorage dễ bị tổn thương bởi XSS.
• Giải pháp tối ưu là tách biệt logic xác thực: API chỉ nhận Bearer token, còn việc quản lý cookie là trách nhiệm của từng client riêng biệt.

Trong thế giới phát triển phần mềm, đôi khi những quyết định tưởng chừng như nhỏ nhặt lại tạo ra những hệ lụy khổng lồ khi hệ thống bắt đầu mở rộng. Tôi đã từng rơi vào cái bẫy tư duy khi cố gắng chọn lựa giữa Cookies và Bearer Tokens mà không thực sự hiểu rõ bản chất của chúng trong các môi trường khác nhau. Một quyết định sai lầm trong thiết kế xác thực không chỉ gây khó khăn cho việc bảo trì mà còn mở ra những lỗ hổng bảo mật không đáng có.

Bản chất của sự khác biệt: Cookies so với Bearer Tokens

Sự khác biệt cốt lõi nằm ở cách thức vận chuyển thông tin xác thực. Với Bearer token, mã nguồn của bạn phải thực hiện thủ công việc đính kèm header Authorization: Bearer <token>. Nếu bạn không viết dòng lệnh đó, yêu cầu sẽ không có quyền truy cập. Ngược lại, Cookies được trình duyệt tự động đính kèm vào mọi yêu cầu gửi đến domain tương ứng.

Lưu ý: Việc lựa chọn không nằm ở cái nào bảo mật hơn, mà là bạn đang bảo mật chống lại mối đe dọa nào. Nếu bạn đang xây dựng hệ thống phức tạp, hãy tham khảo thêm về nghịch lý của những lỗi kỹ thuật tưởng chừng đơn giản để tránh các bẫy tư duy tương tự.

Khi thiết kế xác thực trở thành gánh nặng kỹ thuật

Ban đầu, tôi dự định giữ cookies cho web và thêm một nhánh logic trong Flask để chấp nhận Bearer header cho mobile. Đây là một sai lầm nghiêm trọng. Việc bake "loại client nào đang gọi API" vào backend sẽ khiến logic xác thực trở nên cồng kềnh, khó kiểm thử và cực kỳ rủi ro khi mở rộng. Khi bạn bắt đầu xây dựng các hệ thống quy mô lớn, việc xây dựng quy trình xử lý phụ đề đa ngôn ngữ ưu tiên trình duyệt hay các dịch vụ khác cũng cần sự tách biệt tương tự để đảm bảo tính module hóa.

Giải pháp: Tách biệt lớp xác thực

Thay vì để backend quan tâm đến client, hãy biến API thành Bearer-only. Backend chỉ cần xác thực header Authorization trên mọi route. Mọi vấn đề về lưu trữ token (cookie hay secure storage) nên được xử lý tại phía client.

Sơ đồ kiến trúc đề xuất:

[Client Web] ---> [Cookie HttpOnly] ---> [Next.js Server] ---> [Bearer Header] ---> [API Backend]
[Client Mobile] ---> [Secure Storage] ---> [Bearer Header] ---> [API Backend]

Đánh giá & Lời khuyên Thực tiễn

Từ góc độ của một kỹ sư, việc ép backend phải hỗ trợ nhiều cơ chế xác thực là một "anti-pattern".

• Ưu điểm: Backend trở nên tinh gọn, dễ audit bảo mật và không phụ thuộc vào loại client.
• Nhược điểm: Client phải tự xử lý việc lưu trữ token an toàn (ví dụ: sử dụng Keystore trên Android hoặc Keychain trên iOS).
• Lưu ý Production: Luôn sử dụng SameSite=Lax hoặc Strict cho cookie trên web để ngăn chặn CSRF. Nếu bạn đang làm việc với các hệ thống yêu cầu bảo mật cao, hãy tìm hiểu thêm về kiến trúc định danh cho AI Agent để áp dụng các tiêu chuẩn bảo mật hiện đại nhất.

Câu hỏi thường gặp (FAQ)

Tại sao không nên dùng LocalStorage để lưu token?

LocalStorage không có cơ chế bảo mật chống lại XSS. Nếu trang web của bạn bị chèn mã độc, kẻ tấn công có thể dễ dàng đọc được token.

Bearer token có cần HTTPS không?

Bắt buộc. Vì token được gửi qua header, nếu không có HTTPS, token sẽ bị lộ dưới dạng văn bản thuần túy trong quá trình truyền tải.

Có nên dùng cả hai cùng lúc?

Không nên. Hãy chọn một chuẩn duy nhất cho API backend để giảm thiểu độ phức tạp trong việc bảo trì và kiểm thử bảo mật.

Kết luận

Việc chọn giữa Cookies và Bearer Tokens không chỉ là vấn đề kỹ thuật mà là vấn đề về kiến trúc hệ thống. Bằng cách đẩy trách nhiệm lưu trữ về phía client và giữ cho backend thuần túy, bạn sẽ xây dựng được một hệ thống bền vững hơn. Nếu bạn quan tâm đến việc tối ưu hóa hiệu năng và bảo mật, hãy theo dõi hi_dev để cập nhật những bài viết chuyên sâu tiếp theo. Đừng quên để lại bình luận nếu bạn có cách tiếp cận khác cho bài toán xác thực này!