Session vs Token Based Authentication

0 0 0

Người đăng: PhanDC

Theo Viblo Asia

Xin chào các bạn, ngày hôm nay chúng ta sẽ cùng nhau thảo luận về một chủ đề: Session vs Token Based Authentication.
Đây là 2 phương thức hai phương thức phổ biến nhất để xác thực người dùng trên các hệ thống ứng dụng web. Mình tin chắc rằng đây là những khái niệm quan trọng mà khi chập chững bước vào nghề, chắc hẳn mọi người đều đã từng nghe qua.
Ok mình cùng bắt đầu thôi.

1. Sơ lược về xác thực (Authentication)

Một cách ngắn gọn thì xác thực là quá trình định danh người dùng (user identity) để trả lời câu hỏi: Ai vừa truy cập, gửi yêu cầu tới hệ thống của tôi? Để làm được việc này user sẽ cung cấp thông tin định danh của mình (user credential) thường qua username/password gửi tới server để xác thực.

2. Session-Based Authentication

Cơ chế hoạt động

Sau khi người dùng đăng nhập thành công, serve sẽ tạo ra một Session ID duy nhất và đồng thời lưu lại Session Id này trong trong DB, bộ nhớ RAM của server, etc. Session ID được lưu trữ trong một cookie và gửi về trình duyệt của client. Sau đó, server sẽ sử dụng Session ID này để xác thực các yêu cầu (request) từ cùng một người dùng trong suốt phiên làm việc.

Quá trình xác thực

  1. Người dùng gửi thông tin đăng nhập (username và password).
  2. Máy chủ xác thực và tạo một session ID lưu trữ trong DB. Session ID được lưu trữ trong một cookie và gửi về trình duyệt.
  3. Mỗi yêu cầu tiếp (request) theo từ người dùng sẽ gửi kèm cookie chứa session ID.
  4. Máy chủ kiểm tra session ID trong DB để xác thực người dùng. Nếu tìm thấy ID thì trả về tài nguyên cho user.

Minh họa session based authentication

Ưu điểm

Vì thông tin session được lưu trữ trên DB nên server có toàn quyền kiểm soát session. Một ví dụ cụ thể đó là nếu team security phát hiện một tài khoản bị xâm phạm, họ có thể vô hiệu hóa ID phiên ngay lập tức để người dùng đăng xuất ngay lập tức.

Nhược điểm

Stateful: Máy chủ phải lưu session của người dùng (biến ứng dụng thành stateful application). Do đó không phù hợp cho các hệ thống phân tán hoặc có quy mô lớn, vì cần phải đồng bộ session giữa nhiều máy chủ.
Tài nguyên: Tốn tài nguyên máy chủ để lưu trữ session, đặc biệt nếu số lượng người dùng lớn.

3. Token-Based Authentication (JWT - JSON Web Token)

Cơ chế hoạt động

Sau khi người dùng đăng nhập thành công, máy chủ tạo ra một token định danh người dùng. JWT (Json Web token) là một trong những phương pháp phổ biến được sử dụng. Token được mã hóa, chứa thông tin xác thực (như user ID, quyền truy cập). Sau đó, token này sẽ được gửi về cho client. Token sẽ được lưu trữ ở phía client (thường trong localStorage hoặc session Storage). Tiếp đó, client sẽ được gửi token kèm theo mỗi yêu cầu HTTP trong header (Authorization header) để yêu cầu các quyền truy cập tài nguyên.

Quá trình xác thực

  1. Người dùng gửi thông tin đăng nhập.
  2. Máy chủ xác thực thông tin user và tạo một token mã hóa (JWT). Token được gửi về client và lưu trữ tại localStorage hoặc sessionStorage.
  3. Mỗi yêu cầu tiếp theo sẽ kèm theo token trong phần Authorization header.
  4. Máy chủ kiểm tra tính hợp lệ của token để xác thực người dùng, trả về tài nguyên người dùng yêu cầu

Minh họa token based authentication

Ưu điểm

Stateless: Không cần lưu trữ session trên server, phù hợp với các hệ thống phân tán hoặc microservices.
Dễ dàng mở rộng: Vì không cần đồng bộ trạng thái giữa các máy chủ.

Nhược điểm

Bảo mật: Nếu token bị đánh cắp, kẻ tấn công có thể sử dụng token này để truy cập vào hệ thống cho đến khi token hết hạn.
Quản lý token: Hủy token hoặc làm cho nó hết hiệu lực khó hơn vì máy chủ không lưu trữ trạng thái. Thường phải đợi token hết hạn hoặc sử dụng cơ chế blacklist để vô hiệu hóa.

4. Tổng kết

Session vs Token Based Authentication là hai phương thức phổ biến nhất được ứng dụng cho bài toán xác thực (authentication). Session-Based Authentication phù hợp cho các ứng dụng nhỏ hoặc hệ thống không cần mở rộng quy mô lớn. Trên thực tế, phương thức xác thực bằng session được ứng dụng rất nhiều trong các hệ thống Monolithic.
Token-Based Authentication thường được sử cho các hệ thống phân tán, microservices bởi vì đặc tính stateless không lưu trữ trạng thái token của nó.
Bạn thấy đấy, mỗi phương pháp đều có ưu và nhược điểm riêng. Điều quan trọng là chúng ta làm sao để ứng dụng nó để giải quyết cái bài toán sao cho phù hợp.

Trên đây là bài viết tổng quan về Session vs Token Based Authentication của mình.

Cảm ơn các bạn đã dành thời gian.

Again, mình là Phan

Một chàng developer tò mò và tận tâm.

Hẹn gặp các bạn trong bài viết sắp tới.

Bình luận

Bài viết tương tự

- vừa được xem lúc

Có thực sự an toàn với Authentication và Authorization , mật khẩu có nên lưu ở dạng text ?

Có thực sự an toàn với Authentication và Authorization , mật khẩu có nên lưu ở dạng text . Hơn nữa, vì chúng ta đang lưu trữ thông tin đăng nhập và hỗ trợ quy trình đăng nhập, chúng ta biết rằng sẽ có thông tin xác thực được gửi qua hạ tầng mạng.

0 0 58

- vừa được xem lúc

Login LINE với Firebase Authentication

Ngày nay, khi sử dụng một dịch vụ online online, chúng ta có xu hướng sử dụng một tài khoản liên kết (Google, Facebook, Twitter... tạm gọi là bên thứ 3) để đăng nhập vào dịch vụ đó thay vì cứ mỗi một dịch vụ, ta lại tạo một account/passord riêng. Lúc này Firebase Authentication (từ đây sẽ gọi tắt là

0 0 45

- vừa được xem lúc

Bài 17: Phân quyền trong Laravel

Chào mừng các bạn quay trở lại với series học Laravel với VueJS của mình, ở bài này mình sẽ hướng dẫn các bạn các phân quyền bằng Laravel và VueJS mà không cần cài đặt thêm bất kì package hay library

0 0 94

- vừa được xem lúc

Phân biệt sự khác nhau giữa Authentication và Authorization

Có lẽ trong quá trình lập trình bạn đã được nghe rất nhiều về 2 khái niệm authentication và authorization nhưng liệu bạn đã phân biệt được sự khác nhau giữa 2 khái niệm này? hay đôi khi bạn vẫn mập mờ

0 0 47

- vừa được xem lúc

[Node JS + React JS] - Phần 2 - Authentication server

Hôm nay chúng ta sẽ tiếp tục serie Node JS + React JS với chủ đề là authentication + authorization. Hôm nay chúng ta cùng đi tìm hiểu hai khái niệm cơ bản là Authentication và Authorization, cũng như

0 0 403

- vừa được xem lúc

API với Postman (Phần 3)

Sau 2 bài viết, chúng ta đã hiểu thế nào là client và server, cách chúng sử dụng HTTP để nói chuyện với nhau và việc xác định định dạng dữ liệu để hiểu nhau. Có lẽ trong đầu chúng ta sẽ có câu hỏi: Là

0 0 85