So sánh quản lý phiên cho ứng dụng web: phiên cookie, JWT và refresh token, dùng các mô hình mối đe dọa cụ thể và yêu cầu đăng xuất thực tế.
Phiên là cách ứng dụng của bạn trả lời một câu hỏi sau khi ai đó đăng nhập: "Bạn là ai ngay bây giờ?" Khi câu trả lời đó đáng tin cậy, ứng dụng có thể quyết định người dùng được xem gì, thay đổi gì và hành động nào phải bị chặn.
"Giữ đăng nhập" cũng là một lựa chọn bảo mật. Bạn đang quyết định danh tính người dùng nên còn hợp lệ trong bao lâu, bằng chứng danh tính nằm ở đâu, và chuyện gì xảy ra nếu bằng chứng đó bị sao chép.
Hầu hết thiết lập ứng dụng web dựa vào ba khối xây dựng:
Đây không hẳn là các "phong cách" đối kháng mà là các cách khác nhau để xử lý cùng những đánh đổi: tốc độ vs kiểm soát, đơn giản vs linh hoạt, và "chúng ta có thể vô hiệu hóa ngay bây giờ không?" vs "nó tự hết hạn thế nào?"
Một cách hữu ích để đánh giá bất kỳ thiết kế nào: nếu kẻ tấn công ăn cắp thứ mà app dùng làm bằng chứng (cookie hoặc token), họ có thể làm gì và trong bao lâu? Phiên cookie thường chiếm ưu thế khi bạn cần kiểm soát phía server mạnh mẽ, như đăng xuất cưỡng chế hoặc khoá ngay lập tức. JWT phù hợp cho các kiểm tra không trạng thái giữa các dịch vụ, nhưng chúng gây khó khăn khi bạn cần thu hồi ngay lập tức.
Không có lựa chọn nào thắng ở mọi nơi. Cách làm đúng phụ thuộc vào mô hình mối đe dọa của bạn, mức độ nghiêm ngặt của yêu cầu đăng xuất, và bao nhiêu độ phức tạp đội bạn có thể duy trì.
Thiết kế phiên tốt phụ thuộc ít hơn vào "loại token tốt nhất" và nhiều hơn vào những cuộc tấn công mà bạn thực sự cần chống lại.
Nếu kẻ tấn công đánh cắp dữ liệu từ vùng lưu trữ trình duyệt (như localStorage), access token JWT rất dễ bị lấy vì JavaScript trên trang có thể đọc chúng. Cookie bị đánh cắp khác: nếu cookie được đặt là HttpOnly, mã trang bình thường không thể đọc nó, nên các cuộc tấn công "cướp token" đơn giản khó thực hiện hơn. Nhưng nếu kẻ tấn công có thiết bị (laptop bị mất, malware, máy tính dùng chung), cookie vẫn có thể bị sao chép từ hồ sơ trình duyệt.
XSS (mã tấn công chạy trong trang của bạn) thay đổi mọi thứ. Với XSS, kẻ tấn công có thể không cần phải đánh cắp gì cả. Họ có thể dùng phiên đã đăng nhập của nạn nhân để thực hiện hành động. Cookie HttpOnly giúp ngăn việc đọc bí mật phiên, nhưng không ngăn kẻ tấn công gửi yêu cầu từ trang.
CSRF (một trang khác khởi động hành động không mong muốn) chủ yếu đe doạ các phiên dựa trên cookie, vì trình duyệt tự động đính kèm cookie. Nếu bạn dựa vào cookie, bạn cần phòng thủ CSRF rõ ràng: cấu hình SameSite có chủ ý, token chống CSRF, và xử lý cẩn trọng các yêu cầu thay đổi trạng thái. JWT gửi trong header Authorization ít bị CSRF cổ điển hơn, nhưng vẫn bị phơi nhiễm với XSS nếu lưu nơi JavaScript có thể đọc.
Các tấn công phát lại (tái sử dụng chứng thực bị đánh cắp) là nơi phiên phía server tỏ ra mạnh: bạn có thể vô hiệu hóa session ID ngay lập tức. JWT ngắn hạn giảm thời gian phát lại, nhưng không ngăn phát lại khi token còn hợp lệ.
Thiết bị chia sẻ và điện thoại bị mất biến "đăng xuất" thành một mô hình mối đe dọa thực. Các quyết định thường xoay quanh các câu hỏi như: người dùng có thể ép đăng xuất từ các thiết bị khác không, mất bao lâu để có hiệu lực, chuyện gì xảy ra nếu refresh token bị đánh cắp, và bạn có cho phép phiên "ghi nhớ tôi" không? Nhiều đội cũng áp tiêu chuẩn nghiêm ngặt hơn cho quyền truy cập nhân viên so với khách hàng, điều này thay đổi thời gian chờ và kỳ vọng thu hồi.
Phiên dựa trên cookie là thiết lập cổ điển. Sau khi đăng nhập, server tạo một bản ghi phiên (thường là một ID cộng các trường như user ID, thời gian tạo và hạn hết). Trình duyệt chỉ lưu ID phiên trong cookie. Trên mỗi yêu cầu, trình duyệt gửi cookie đó và server tra cứu phiên để quyết định người dùng là ai.
Ưu thế bảo mật lớn là khả năng kiểm soát. Phiên được xác thực trên server mỗi lần. Nếu bạn cần đá ai đó ra, bạn xóa hoặc vô hiệu hóa bản ghi phiên phía server và nó ngừng hoạt động ngay lập tức, ngay cả khi người dùng vẫn còn cookie.
Phần lớn bảo vệ đến từ cấu hình cookie:
Nơi bạn lưu trạng thái phiên ảnh hưởng đến khả năng scale. Giữ session trong bộ nhớ app thì đơn giản, nhưng vỡ khi chạy nhiều server hoặc khởi động lại thường xuyên. Cơ sở dữ liệu hoạt động tốt cho độ bền. Redis phổ biến khi bạn muốn lookup nhanh và nhiều phiên đang hoạt động. Điểm then chốt là như nhau: server phải có khả năng tìm và xác thực phiên trên mỗi yêu cầu.
Phiên cookie phù hợp mạnh mẽ khi bạn cần hành vi đăng xuất nghiêm ngặt, như dashboard nhân viên hoặc cổng khách hàng nơi admin phải ép đăng xuất sau khi thay đổi vai trò. Nếu một nhân viên rời đi, vô hiệu hóa các phiên phía server của họ sẽ chấm dứt quyền truy cập ngay, không phải chờ token hết hạn.
JWT (JSON Web Token) là một chuỗi đã ký chứa vài claims về người dùng (như user ID, role, tenant) cộng thời gian hết hạn. API của bạn xác minh chữ ký và thời hạn tại chỗ, không cần gọi cơ sở dữ liệu, rồi ủy quyền yêu cầu.
Đó là lý do JWT phổ biến trong sản phẩm API-first, app mobile, và hệ thống nơi nhiều dịch vụ cần xác thực cùng một danh tính. Nếu bạn có nhiều instance backend, mỗi instance có thể xác minh cùng một token và nhận cùng câu trả lời.
Access token JWT kiểm tra nhanh và dễ đính kèm theo các cuộc gọi API. Nếu frontend gọi nhiều endpoint, một access token ngắn hạn có thể giữ luồng đơn giản: xác minh chữ ký, đọc user ID, tiếp tục.
Ví dụ: một cổng khách hàng gọi "Liệt kê hoá đơn" và "Cập nhật hồ sơ" trên các dịch vụ riêng biệt. Một JWT có thể chứa customer ID và một role như customer, nên mỗi service có thể ủy quyền mà không cần tra cứu session mỗi lần.
Đối đổi lớn nhất là thu hồi. Nếu token còn hiệu lực một giờ, thường thì token đó còn hợp lệ ở mọi nơi trong một giờ, ngay cả khi người dùng nhấn "log out" hoặc admin vô hiệu hóa tài khoản, trừ khi bạn thêm kiểm tra phía server.
JWT cũng rò rỉ theo những cách thông thường. Các điểm hỏng phổ biến bao gồm localStorage (XSS có thể đọc), bộ nhớ trình duyệt (extension độc hại), logs và báo cáo lỗi, proxy và công cụ phân tích ghi lại header, và token bị sao chép vào chat hỗ trợ hoặc ảnh màn hình.
Vì vậy, access token JWT phù hợp nhất cho truy cập ngắn hạn, không phải "đăng nhập mãi mãi." Giữ chúng ít nhất có thể (không chứa dữ liệu cá nhân nhạy cảm), để thời hạn ngắn, và giả sử token bị đánh cắp sẽ sử dụng được cho đến khi nó hết hạn.
Access token JWT dành cho thời hạn ngắn. Điều đó tốt cho an toàn, nhưng tạo ra vấn đề thực tế: người dùng không nên phải đăng nhập lại mỗi vài phút. Refresh token giải quyết bằng cách cho phép app lấy thầm access token mới khi token cũ hết hạn.
Nơi bạn lưu refresh token còn quan trọng hơn nơi lưu access token. Trong web app, mặc định an toàn nhất là cookie HttpOnly, Secure để JavaScript không đọc được. Lưu trong localStorage dễ triển khai hơn, nhưng cũng dễ bị đánh cắp hơn nếu có lỗi XSS. Nếu mô hình mối đe dọa của bạn bao gồm XSS, tránh đặt bí mật dài hạn ở nơi JavaScript có thể truy cập.
Xoay vòng (rotation) là thứ làm cho refresh token có thể dùng trong hệ thống thực tế. Thay vì dùng cùng một refresh token trong nhiều tuần, bạn hoán đổi nó mỗi lần dùng: client trình refresh token A, server cấp access token mới cộng refresh token B, và refresh token A bị vô hiệu.
Một thiết lập xoay vòng đơn giản thường theo vài quy tắc:
Phát hiện tái sử dụng là cảnh báo then chốt. Nếu refresh token A đã được đổi, nhưng bạn thấy nó xuất hiện lại sau đó, hãy giả định nó đã bị sao chép. Phản ứng thông thường là thu hồi toàn bộ phiên (và thường là tất cả phiên cho người dùng đó) và yêu cầu đăng nhập lại, vì bạn không biết bản sao nào là thật.
Với logout, bạn cần thứ server có thể thực thi. Thường điều đó nghĩa là một bảng session (hoặc danh sách thu hồi) đánh dấu refresh token bị thu hồi. Access token có thể vẫn hoạt động cho đến khi hết hạn, nhưng bạn có thể giữ cửa sổ đó nhỏ bằng cách giữ access token ngắn hạn.
Đăng xuất nghe có vẻ đơn giản cho đến khi bạn định nghĩa nó. Thường có hai yêu cầu khác nhau: "đăng xuất thiết bị này" (một trình duyệt hoặc một điện thoại) và "đăng xuất mọi nơi" (tất cả các phiên đang hoạt động trên mọi thiết bị).
Cũng có câu hỏi về thời gian. "Đăng xuất ngay lập tức" nghĩa là app ngừng chấp nhận chứng thực ngay bây giờ. "Đăng xuất sau khi hết hạn" nghĩa là app ngừng chấp nhận nó khi phiên hoặc token hiện tại tự hết hạn.
Với phiên dựa trên cookie, đăng xuất ngay lập tức dễ làm vì server sở hữu phiên. Bạn xóa cookie trên client và vô hiệu hóa bản ghi phiên phía server. Nếu ai đó đã sao chép giá trị cookie trước đó, chính từ chối phía server là thứ thực sự thực thi đăng xuất.
Với xác thực chỉ bằng JWT (access token không trạng thái và không tra cứu phía server), bạn không thể đảm bảo đăng xuất ngay lập tức. JWT bị đánh cắp vẫn còn hợp lệ cho đến khi nó hết hạn, vì server không có chỗ nào để kiểm tra "token này đã bị thu hồi không?" Bạn có thể thêm denylist, nhưng khi đó bạn đang giữ trạng thái và kiểm tra nó, điều này làm mất nhiều sự đơn giản ban đầu.
Một mẫu thực tế là coi access token là ngắn hạn và thi hành đăng xuất thông qua refresh token. Access token được cho phép chờ trong vài phút, nhưng refresh token là thứ giữ cho phiên sống. Nếu laptop bị mất, thu hồi gia đình refresh token cắt đứt truy cập tương lai nhanh chóng.
Những gì bạn có thể hứa thực tế với người dùng:
Với thay đổi mật khẩu và vô hiệu tài khoản, đừng dựa vào "người dùng sẽ đăng xuất." Lưu một phiên bản phiên trên toàn tài khoản (hoặc một dấu thời gian "token hợp lệ sau"). Trên mỗi refresh (và đôi khi trên mỗi yêu cầu), so sánh nó. Nếu nó thay đổi, từ chối và yêu cầu đăng nhập lại.
Nếu bạn muốn thiết kế phiên đơn giản, hãy quyết định quy tắc trước rồi mới chọn cơ chế. Hầu hết vấn đề bắt đầu khi các đội chọn JWT hoặc cookie vì chúng phổ biến, chứ không phải vì phù hợp với rủi ro và yêu cầu đăng xuất.
Bắt đầu bằng cách liệt kê mọi nơi người dùng đăng nhập. Một app trên trình duyệt hành xử khác so với app native mobile, công cụ quản trị nội bộ, hoặc tích hợp đối tác. Mỗi thứ thay đổi nơi có thể lưu an toàn, cách làm mới đăng nhập, và "đăng xuất" nên nghĩa là gì.
Một thứ tự thực tế phù hợp với hầu hết đội:
Rồi tài liệu hoá các lời hứa chính xác hệ thống của bạn đưa ra. Ví dụ: "Phiên web hết sau 30 phút không hoạt động hoặc 7 ngày tuyệt đối. Admin có thể ép đăng xuất trong vòng 60 giây. Điện thoại mất có thể bị vô hiệu từ xa." Những câu đó quan trọng hơn thư viện bạn dùng.
Cuối cùng, thêm giám sát phù hợp với mẫu của bạn. Với thiết lập token, tín hiệu mạnh là tái sử dụng refresh token (cùng refresh token được dùng hai lần). Xử lý như khả năng bị đánh cắp, thu hồi chuỗi phiên, và cảnh báo người dùng.
Hầu hết chiếm đoạt tài khoản không phải là "hack tinh vi." Chúng là những chiến thắng đơn giản do sai lầm phiên dễ dự đoán. Xử lý phiên tốt chủ yếu là không cho kẻ tấn công một cách dễ dàng để đánh cắp hoặc phát lại chứng thực.
Một bẫy phổ biến là đặt access token trong localStorage và hy vọng bạn không bao giờ gặp XSS. Nếu bất kỳ script nào chạy trên trang của bạn (một phụ thuộc xấu, widget bị chèn, một bình luận lưu), nó có thể đọc localStorage và gửi token ra ngoài. Cookie với cờ HttpOnly giảm rủi ro đó vì JavaScript không thể đọc chúng.
Bẫy khác là làm JWT tồn tại lâu để tránh refresh token. Access token 7 ngày là cửa sổ tái sử dụng 7 ngày nếu nó rò rỉ. Access token ngắn và refresh token được quản lý tốt khó bị lạm dụng hơn, đặc biệt khi bạn có thể cắt quyền refresh.
Cookie cũng có nguy cơ riêng: quên phòng thủ CSRF. Nếu app bạn dùng cookie để xác thực và bạn chấp nhận các yêu cầu thay đổi trạng thái mà không có bảo vệ CSRF, một trang độc hại có thể lừa trình duyệt đã đăng nhập gửi yêu cầu hợp lệ.
Các sai lầm khác thường xuất hiện sau reviews sự cố:
Một ví dụ cụ thể: một nhân viên hỗ trợ dán "log gỡ lỗi" vào ticket. Log bao gồm header Authorization. Ai có quyền truy cập ticket có thể phát lại token đó và hành động như nhân viên. Xử lý token như mật khẩu: đừng in chúng, đừng lưu chúng, và giữ chúng có thời hạn ngắn.
Phần lớn lỗi phiên không phải về crypto cao siêu. Làm mất một cờ, một token sống quá lâu, hoặc một endpoint lẽ ra phải yêu cầu xác thực lại.
Trước khi phát hành, làm một lượt kiểm tra tập trung vào những gì kẻ tấn công có thể làm với cookie hoặc token bị đánh cắp. Đó là một trong những cách nhanh nhất để cải thiện bảo mật mà không viết lại toàn bộ hệ thống auth.
Thực hiện các kiểm tra này trên staging, rồi lặp lại ở production:
Sau đó, kiểm tra các lời hứa đăng xuất của bạn. "Đăng xuất" thường nghĩa là "xóa phiên cục bộ," nhưng người dùng mong đợi hơn thế.
Một kiểm tra thực tế: đăng nhập trên laptop và điện thoại, rồi đổi mật khẩu. Laptop nên bị bắt đăng xuất ở yêu cầu tiếp theo, không phải vài giờ sau. Nếu bạn cung cấp "đăng xuất mọi nơi" và danh sách thiết bị, xác nhận mỗi thiết bị tương ứng với một phiên hoặc bản ghi refresh token bạn có thể thu hồi.
Hình dung một doanh nghiệp nhỏ có cổng khách hàng web (khách xem hoá đơn, mở ticket) và app mobile cho nhân viên hiện trường (công việc, ghi chú, ảnh). Nhân viên đôi khi làm việc ở tầng hầm không có sóng, nên app cần hoạt động ngoại tuyến trong một thời gian. Admin cũng muốn một nút đỏ lớn: nếu máy tính bảng bị mất hoặc nhà thầu rời đi, họ có thể ép đăng xuất.
Bây giờ thêm ba mối đe dọa phổ biến: máy tính bảng dùng chung trên xe (ai đó quên đăng xuất), phishing (nhân viên nhập thông tin vào trang giả), và một lỗi XSS thỉnh thoảng trong portal (một script chạy trên trình duyệt và cố gắng ăn cắp những gì có thể).
Thiết lập thực tế ở đây là access token ngắn hạn cộng với refresh token xoay vòng, kèm thu hồi phía server. Nó cho bạn cuộc gọi API nhanh và chịu được làm việc ngoại tuyến, trong khi vẫn cho phép admin cắt quyền truy cập.
Đây là cách nhìn thực tế:
Đăng xuất cưỡng chế trở nên có thể thi hành: admin thu hồi bản ghi refresh token cho thiết bị đó (hoặc cho tất cả thiết bị của người dùng). Thiết bị bị đánh cắp có thể tiếp tục dùng access token hiện tại cho đến khi nó hết hạn, nhưng không thể lấy token mới. Vì vậy thời gian tối đa để cắt hoàn toàn truy cập là thời hạn access token của bạn.
Với thiết bị mất, định nghĩa quy tắc bằng ngôn ngữ rõ ràng: "Trong vòng 10 phút, app sẽ ngừng đồng bộ và yêu cầu đăng nhập lại." Công việc ngoại tuyến có thể vẫn nằm trên thiết bị, nhưng lần đồng bộ trực tuyến tiếp theo sẽ thất bại cho đến khi người dùng đăng nhập.
Viết rõ "đăng xuất" nghĩa là gì bằng ngôn ngữ sản phẩm. Ví dụ: "Đăng xuất xoá quyền truy cập trên thiết bị này," "Đăng xuất mọi nơi đá tất cả thiết bị trong vòng 1 phút," hoặc "Đổi mật khẩu đăng xuất các phiên khác." Những lời hứa đó quyết định bạn cần trạng thái phiên phía server, danh sách thu hồi, hay token ngắn hạn.
Chuyển các lời hứa thành kế hoạch thử nhỏ. Bug liên quan token và phiên thường trông ổn trong kịch bản đường vui vẻ, rồi thất bại trong thực tế (chế độ ngủ, mạng chập chờn, nhiều thiết bị).
Chạy các test bao phủ các trường hợp lộn xộn:
Sau các test, làm một buổi diễn tập tấn công đơn giản với đội. Chọn ba câu chuyện và đi qua từng bước: một lỗi XSS có thể đọc token, một cuộc tấn công CSRF vào phiên cookie, và một điện thoại bị đánh cắp có phiên đang hoạt động. Bạn đang kiểm tra liệu thiết kế có khớp với các lời hứa hay không.
Nếu cần chạy nhanh, giảm mã glue tùy chỉnh. AppMaster (appmaster.io) là một lựa chọn khi bạn muốn backend sinh sẵn, sẵn sàng cho sản xuất cùng web và app native, để giữ các quy tắc như expiry, rotation và forced logout nhất quán giữa các client.
Lên lịch review sau khi ra mắt. Dùng ticket hỗ trợ thực tế và sự cố để điều chỉnh thời hạn, giới hạn phiên, và hành vi "đăng xuất mọi nơi," rồi chạy lại cùng checklist để đảm bảo sửa lỗi không bị quay lại.
21 thg 1, 2026
8 phút
20 thg 1, 20268 phút
20 thg 1, 20268 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
