Authentication Pattern
Authentication Pattern
Authentication Pattern là mẫu thiết kế giúp xác minh danh tính của người dùng hoặc dịch vụ trước khi cho phép truy cập vào hệ thống microservices. Nó đảm bảo rằng chỉ những thực thể hợp lệ mới có quyền thực hiện các hành động cụ thể.
Cơ chế hoạt động
Cơ chế hoạt động của authentication trong microservices thường gồm các bước sau:
Client gửi yêu cầu xác thực
Người dùng nhập thông tin đăng nhập (username/password, token, API key...).
Hệ thống gửi thông tin này đến một dịch vụ xác thực (Authentication Service).
Dịch vụ xác thực kiểm tra thông tin
Hệ thống kiểm tra thông tin đăng nhập với cơ sở dữ liệu (DB, LDAP, OAuth, OpenID...).
Nếu thông tin hợp lệ, hệ thống tạo token xác thực (JWT, OAuth token).
Client sử dụng token để truy cập microservices
Sau khi nhận được token, client gửi token này trong header của các request tiếp theo.
Mỗi microservice kiểm tra tính hợp lệ của token trước khi xử lý request.
Trường hợp sử dụng
Authentication Pattern được áp dụng trong các trường hợp:
Xác thực người dùng khi đăng nhập vào hệ thống (ứng dụng web, mobile).
Xác thực API client khi truy cập các dịch vụ microservices.
Xác thực giữa các microservices khi giao tiếp nội bộ.
Xác thực dựa trên OAuth, OpenID cho các ứng dụng bên thứ ba.
Cách triển khai
1. Xác thực dựa trên phiên làm việc (Session-Based Authentication):
Quy trình hoạt động:
Người dùng đăng nhập: Người dùng gửi thông tin xác thực (như tên người dùng và mật khẩu) đến máy chủ thông qua một yêu cầu đặc biệt.
Kiểm tra thông tin: Máy chủ xác minh xem thông tin cung cấp có khớp với dữ liệu lưu trữ hay không.
Tạo phiên làm việc: Nếu thông tin chính xác, máy chủ tạo một "phiên làm việc" chứa thông tin người dùng (như ID người dùng, quyền hạn và thời gian hiệu lực). Thông tin này được lưu trữ an toàn trên máy chủ.
Gửi ID phiên làm việc: Máy chủ gửi lại "ID phiên làm việc" cho thiết bị của người dùng, thường dưới dạng cookie trong phản hồi.
Sử dụng ID phiên làm việc: Trong các yêu cầu tiếp theo, thiết bị của người dùng tự động kèm theo ID phiên làm việc trong các yêu cầu gửi đến máy chủ.
Xác minh trên máy chủ: Máy chủ sử dụng ID phiên làm việc để truy xuất thông tin phiên tương ứng từ bộ nhớ và xác định người dùng.
Cấp quyền truy cập: Nếu thông tin hợp lệ, máy chủ cho phép người dùng truy cập vào tài nguyên hoặc dịch vụ yêu cầu.
Ưu điểm:
Dữ liệu phiên làm việc được lưu trữ an toàn trên máy chủ, giảm nguy cơ bị đánh cắp thông tin nhạy cảm từ phía client.
Dễ dàng quản lý và hủy bỏ phiên làm việc khi cần, cho phép kiểm soát tốt hơn đối với các phiên hoạt động.
Nhược điểm:
Không phù hợp cho các ứng dụng phân tán hoặc cần mở rộng, vì việc chia sẻ trạng thái phiên làm việc giữa các máy chủ đòi hỏi cấu hình phức tạp.
Tăng tải cho máy chủ do phải lưu trữ thông tin phiên làm việc cho mỗi người dùng.
2. Xác thực dựa trên token (Token-Based Authentication):
Quy trình hoạt động:
Người dùng đăng nhập: Người dùng gửi thông tin xác thực đến máy chủ.
Xác minh thông tin: Máy chủ kiểm tra tính hợp lệ của thông tin.
Tạo token: Sau khi xác thực thành công, máy chủ tạo một token (thường là JWT - JSON Web Token) chứa thông tin người dùng, quyền hạn, thời gian hết hạn của token và gửi lại cho người dùng.
Token signing và hashsing: Để bảo mật thông tin token thường được ký bởi một secret key bằng một thuật toán (ví dụ SHA256).
Gửi token cho client: Server sẽ gửi token này cho client.
Lưu trữ token: Token này được lưu trữ trên phía client, có thể trong localStorage hoặc sessionStorage.
Gửi token trong yêu cầu: Trong các yêu cầu tiếp theo, client gửi kèm token trong header của HTTP request.
Xác minh token: Máy chủ xác minh tính hợp lệ của token và, nếu hợp lệ, xử lý yêu cầu.
Ưu điểm:
Phù hợp cho các ứng dụng phân tán và microservices, vì token có thể được xác thực độc lập mà không cần lưu trữ trạng thái trên máy chủ.
Giảm tải cho máy chủ do không cần lưu trữ thông tin phiên làm việc.
Nhược điểm:
Nếu token bị lộ, kẻ tấn công có thể sử dụng cho đến khi token hết hạn, gây rủi ro bảo mật.
Việc thu hồi token trước khi hết hạn có thể phức tạp, đặc biệt trong các hệ thống phân tán.
Việc lựa chọn giữa hai phương pháp này phụ thuộc vào yêu cầu cụ thể của ứng dụng, như khả năng mở rộng, bảo mật và kiến trúc hệ thống.
Câu hỏi liên quan
Tại sao sử dụng session base authentication lại giảm nguy cơ bị đánh cắp thông tin nhạy cảm từ phía client?
Trong Session-Based Authentication, thông tin xác thực của người dùng (ví dụ: username, quyền hạn, trạng thái đăng nhập) được lưu trên máy chủ thay vì client.
Client chỉ giữ session ID, thường được lưu trong cookie. Session ID không chứa thông tin người dùng mà chỉ là một mã tham chiếu đến phiên làm việc trên máy chủ.
Nếu attacker lấy được session ID, họ vẫn không thể biết thông tin đăng nhập của người dùng.
Nếu phát hiện thấy phiên bị đánh cắp hoặc có hoạt động đáng ngờ, máy chủ có thể xóa session ngay lập tức. Trong khi đó, với token, nếu không có cơ chế token revocation, attacker có thể tiếp tục sử dụng token cho đến khi hết hạn.
Session ID có thể được lưu trong Secure HttpOnly Cookie, giúp:
Ngăn chặn JavaScript truy cập: Tránh bị đánh cắp bởi các cuộc tấn công XSS (Cross-Site Scripting).
Chỉ gửi qua HTTPS: Ngăn chặn tấn công Man-in-the-Middle (MITM).
Máy chủ có thể kiểm soát thời gian sống của phiên (session timeout) và buộc người dùng đăng nhập lại sau một khoảng thời gian nhất định.
Điều này giúp giảm khả năng attacker sử dụng session bị đánh cắp trong thời gian dài.
Thế còn token base authentication thì sao?
Với Token-Based Authentication (như JWT), token chứa đầy đủ thông tin người dùng (ví dụ: username, roles, thời gian hết hạn) và được lưu trên client (localStorage hoặc cookie).
Nếu attacker đánh cắp được token, họ có thể sử dụng nó để truy cập hệ thống mà không cần biết username và password. Trong khi Session-Based Authentication, ngay cả khi session ID bị lộ, nó chỉ có giá trị khi máy chủ còn giữ phiên làm việc đó.