Giới thiệu
Trong bài viết trước về bảo mật Django, tôi đã đề cập đến cách làm cứng một dự án Django: từ các cài đặt và middleware an toàn đến các thực tiễn triển khai và thậm chí là kiểm soát tần suất yêu cầu với Django REST Framework (DRF). Tuy nhiên, bài viết đó chủ yếu tập trung vào bảo mật ứng dụng web truyền thống.
Ngày nay, Django cũng cung cấp nền tảng cho API — cho các ứng dụng đơn trang (SPA), ứng dụng di động hoặc tích hợp bên ngoài. Việc bảo mật các API này đem lại những thách thức riêng và yêu cầu phải xem xét cẩn thận các phương thức xác thực. Trong bài viết này, chúng ta sẽ phân tích các phương pháp chính để xác thực API trong Django, các gói bên thứ ba hỗ trợ chúng và sự đánh đổi giữa tính khả dụng và bảo mật.
1. Xác thực Phiên + CSRF
Định nghĩa
Đây là quy trình xác thực truyền thống của Django: người dùng đăng nhập, máy chủ tạo một phiên, và trình duyệt nhận một cookie phiên. Các API cũng có thể sử dụng điều này thông qua SessionAuthentication của DRF, điều này bắt buộc phải có mã thông báo CSRF.
Ưu điểm:
- Kiểm tra và đã được kiểm toán.
- Bảo vệ CSRF tích hợp khi sử dụng cookie.
- Dễ dàng hủy bỏ phiên khi đăng xuất.
Nhược điểm:
- Không lý tưởng cho các khách hàng không phải trình duyệt (ứng dụng di động, API của bên thứ ba).
- Yêu cầu lưu trữ phiên chung nếu bạn mở rộng theo chiều ngang.
Tác động của kiểm soát tần suất:
Ngay cả với CSRF, một kẻ tấn công vẫn có thể cố gắng đăng nhập brute-force hoặc sử dụng credential stuffing. Các cơ chế kiểm soát tần suất của DRF (AnonRateThrottle, UserRateThrottle) giúp ngăn chặn lạm dụng, đặc biệt là trên các điểm cuối đăng nhập.
2. Xác thực Token Đơn Giản
Định nghĩa
DRF cung cấp một hệ thống TokenAuthentication đơn giản: người dùng đăng nhập, nhận một chuỗi token và gửi nó với mỗi yêu cầu (Authorization: Token <token>).
Ưu điểm:
- Đơn giản để triển khai và sử dụng.
- Token có thể bị thu hồi thủ công bằng cách xóa chúng.
Nhược điểm:
- Token không hết hạn theo mặc định.
- Nếu một token bị rò rỉ, nó có thể được sử dụng vô thời hạn.
Tác động của kiểm soát tần suất:
Các API sử dụng xác thực token luôn nên kiểm soát tần suất cho các điểm cuối đăng nhập hoặc phát hành token để giảm thiểu các cuộc tấn công brute force. Nếu không có kiểm soát tần suất, một token bị rò rỉ hoặc mật khẩu yếu có thể bị khai thác nhanh chóng.
3. JWT (JSON Web Tokens) với Token Truy cập + Làm mới
Định nghĩa
JWT là các token không trạng thái, đã ký. Thông thường, các token truy cập có thời gian sống ngắn được kết hợp với các token làm mới có thời gian sống dài hơn. Triển khai phổ biến: Simple JWT.
Ưu điểm:
- Xác thực không trạng thái, tuyệt vời cho các dịch vụ vi mô.
- Token có thời gian sống ngắn giảm khả năng tiếp xúc nếu bị xâm phạm.
- Có thể xoay vòng token làm mới.
Nhược điểm:
- Việc thu hồi là khó khăn mà không có danh sách đen.
- Việc đánh cắp token làm mới là một rủi ro lớn.
Tác động của kiểm soát tần suất:
Bởi vì JWT thường được sử dụng trong các API có lưu lượng truy cập cao, kiểm soát tần suất cho các điểm cuối làm mới là rất quan trọng. Nếu không có nó, kẻ tấn công có thể cố gắng phát lại token hoặc brute force các token làm mới bị đánh cắp.
4. Django-Rest-Knox
Định nghĩa
Knox cải tiến hệ thống token của DRF bằng cách hỗ trợ các token riêng cho từng thiết bị, thời gian hết hạn tự động và xử lý đăng xuất tốt hơn.
Ưu điểm:
- Thời gian hết hạn token tích hợp.
- Việc thu hồi hoạt động theo từng thiết bị.
- An toàn hơn so với hệ thống token đơn giản của DRF.
Nhược điểm:
- Token được lưu trữ ở phía máy chủ, do đó ít “không trạng thái” hơn so với JWT.
- Yêu cầu lưu trữ chung trong các hệ thống phân tán.
Tác động của kiểm soát tần suất:
Knox đã tự động hết hạn token, nhưng bạn nên kiểm soát tần suất cho các điểm cuối tạo token. Nếu không, một kẻ tấn công có thể làm ngập hệ thống với các yêu cầu token, gây ra vấn đề vận hành hoặc bảo mật.
5. Thư viện Hỗ trợ: allauth, dj-rest-auth, và Djoser
- django-allauth – Xử lý đăng ký, đăng nhập, xác thực xã hội và xác minh email. Thường được kết hợp với phiên, nhưng có thể tích hợp với API.
- dj-rest-auth – Các điểm cuối REST cho đăng nhập, đăng xuất, quản lý mật khẩu và đăng ký. Có thể hoạt động với cả token và JWT.
- Djoser – Triển khai REST của hệ thống xác thực Django. Cung cấp các điểm cuối sẵn có cho đăng ký, đăng nhập và đặt lại mật khẩu với hỗ trợ cho token hoặc JWT.
Tác động của kiểm soát tần suất:
Các điểm cuối đăng ký, đăng nhập và đặt lại mật khẩu là những mục tiêu lạm dụng phổ biến. Kiểm soát tần suất của DRF (ScopedRateThrottle) cho phép bạn đặt giới hạn nghiêm ngặt hơn chỉ cho những điểm cuối nhạy cảm này.
6. OAuth2 và Bộ công cụ Django OAuth
Đối với các trường hợp sử dụng nâng cao hơn (truy cập ủy quyền, nhà cung cấp danh tính bên ngoài), Bộ công cụ Django OAuth cung cấp hỗ trợ OAuth2 / OIDC. Nó nặng hơn so với JWT hoặc Knox nhưng hữu ích cho các kịch bản doanh nghiệp.
Tác động của kiểm soát tần suất:
Các điểm cuối token OAuth (/token, /authorize) luôn nên được kiểm soát tần suất, vì chúng là mục tiêu chính cho các cuộc tấn công brute-force.
7. Bảng So Sánh
| Tính năng | Phiên + CSRF | Xác thực Token | JWT | Knox |
|---|---|---|---|---|
| Không trạng thái | ❌ | ❌ (cần tra cứu) | ✅ | ❌ |
| Thu hồi | ✅ | ✅ (xóa token) | ⚠️ (cần danh sách đen) | ✅ |
| Hoạt động cho trình duyệt | ✅ | ✅ | ✅ | ✅ |
| Hoạt động cho ứng dụng di động | ⚠️ | ✅ | ✅ | ✅ |
| Thời gian hết hạn tích hợp | Thời gian hết hạn phiên | ❌ | ✅ | ✅ |
| Tác động của kiểm soát tần suất | Thực sự cần kiểm soát tần suất đăng nhập | Kiểm soát tần suất phát hành token | Kiểm soát tần suất làm mới rất quan trọng | Kiểm soát tần suất tạo token |
8. Các Thực tiễn Bảo mật Tốt nhất
Bất kể phương pháp nào:
- Kiểm soát tần suất cho các điểm nhạy cảm: đăng nhập, đặt lại mật khẩu, điểm cuối token/làm mới.
- Sử dụng HTTPS ở mọi nơi.
- Token có thời gian sống ngắn với xoay vòng (đối với JWT).
- Cookie HttpOnly + Secure (đối với phiên hoặc JWT lưu trữ trong cookie).
- Danh sách đen hoặc thu hồi token khi mật khẩu thay đổi.
- Nhật ký kiểm tra: theo dõi các lần đăng nhập thất bại, sử dụng token bất thường.
9. Bạn Nên Chọn Phương Pháp Nào?
- Các ứng dụng web bạn hoàn toàn kiểm soát → Xác thực phiên với CSRF là đơn giản và an toàn nhất.
- Khách hàng di động hoặc bên thứ ba → JWT với token làm mới (thông qua Simple JWT + dj-rest-auth hoặc Djoser).
- Cần thu hồi theo từng thiết bị, nhưng không cần độ phức tạp của JWT → Knox.
- Doanh nghiệp với các nhà cung cấp danh tính bên ngoài → OAuth2 (Bộ công cụ Django OAuth).
Luôn kết hợp với kiểm soát tần suất DRF trên các điểm nhạy cảm để giảm thiểu rủi ro tấn công brute force và lạm dụng.
10. Kết luận
Việc xác thực API trong Django không phải là một giải pháp duy nhất cho tất cả. Lựa chọn đúng phụ thuộc vào khách hàng của bạn, nhu cầu mở rộng và mô hình đe dọa. Dù bạn chọn phiên, token, JWT, Knox hay OAuth2, điều quan trọng nhất là cấu hình nó một cách an toàn — và đừng quên rằng kiểm soát tần suất cũng là một phần quan trọng của bảo mật API như xác thực chính nó.
