Authentication và authorization là hai khái niệm backend thường bị dùng lẫn. Authentication trả lời câu hỏi “người dùng là ai?”, còn authorization trả lời “người đó được phép làm gì?”. Nhầm hai lớp này có thể tạo ra lỗi nghiêm trọng: user đăng nhập hợp lệ nhưng xem hoặc sửa được dữ liệu không thuộc quyền của mình.
Bài viết này đi từ nền tảng đến checklist production cho backend developer: session, JWT, middleware, RBAC, ABAC, object-level permission, audit log và các lỗi triển khai hay gặp.
Authentication khác Authorization thế nào?
Authentication là quá trình xác minh danh tính: email/password, magic link, OAuth, SSO, passkey hoặc MFA. Sau khi xác thực thành công, backend tạo session hoặc token để nhận diện user ở các request sau.
Authorization là quá trình kiểm tra quyền: user này có được xem invoice này không, có được approve payout không, có được gọi API admin không, có được sửa resource thuộc team khác không.
Authentication flow trong backend
Một authentication flow production thường có các bước:
- Nhận credential hoặc identity assertion từ client.
- Validate input và rate limit để chống brute force.
- Kiểm tra user, password hash hoặc provider token.
- Áp dụng MFA/risk check nếu cần.
- Tạo session/token có thời hạn rõ ràng.
- Ghi audit event như login success/failure.
Password phải được hash bằng thuật toán phù hợp như Argon2, bcrypt hoặc scrypt; không bao giờ lưu plain text. Với OAuth/SSO, backend vẫn cần validate issuer, audience, expiry, signature và mapping user nội bộ.
Authorization model: RBAC, ABAC và policy
RBAC gán quyền theo role: admin, manager, member, viewer. Đây là mô hình dễ bắt đầu và phù hợp với nhiều SaaS nội bộ.
ABAC quyết định quyền theo thuộc tính: department, region, ownership, resource status, risk level. Mô hình này linh hoạt hơn nhưng phức tạp hơn.
Với codebase lớn, nên đưa authorization vào policy layer thay vì rải rác trong controller:
can_update_project?(user, project)
can_approve_invoice?(user, invoice)Policy function giúp test dễ hơn, review bảo mật rõ hơn và giảm nguy cơ endpoint quên check quyền.
Object-level permission: nơi nhiều hệ thống bị thủng
Lỗi phổ biến nhất không phải là “chưa đăng nhập vẫn vào được”, mà là đã đăng nhập nhưng truy cập được object của người khác. Ví dụ:
GET /api/invoices/123Nếu backend chỉ kiểm current_user != null mà không kiểm invoice 123 thuộc user/team nào, đây là lỗi broken access control.
Pattern an toàn hơn:
invoice = current_user.team.invoices.find(params[:id])hoặc policy rõ ràng:
authorize!(current_user, :read, invoice)JWT hay session?
Không có câu trả lời tuyệt đối. Session cookie phù hợp với web app truyền thống, dễ revoke, dễ quản lý server-side. JWT phù hợp cho API/mobile/microservices nếu bạn cần stateless verification, nhưng khó revoke hơn nếu thiết kế thiếu refresh token/blacklist/short TTL.
| Tiêu chí | Session | JWT |
|---|---|---|
| Revoke | Dễ | Cần thiết kế thêm |
| Stateless | Không | Có |
| Payload | Lưu server-side | Có thể chứa claim, nhưng không chứa bí mật |
| Rủi ro | CSRF nếu cookie sai cấu hình | Token leak, TTL dài, claim stale |
Với JWT, cần chú ý: TTL ngắn, refresh token rotation, validate signature, issuer, audience, expiry; không tin role trong token nếu quyền thay đổi thường xuyên mà không có cơ chế refresh/revoke.
Security checklist cho backend production
- Tách rõ middleware authentication và policy authorization.
- Mọi endpoint đọc/sửa resource đều có object-level permission.
- Password hash bằng thuật toán mạnh, có rate limit login.
- Session cookie có
HttpOnly,Secure,SameSitephù hợp. - JWT có TTL ngắn, validate đầy đủ issuer/audience/signature.
- Admin action có audit log: ai, làm gì, resource nào, lúc nào.
- Test có case “user A không được xem resource user B”.
- Không expose token trong URL, log hoặc error message.
- Có quy trình revoke khi user nghỉ việc, mất thiết bị hoặc role đổi.
FAQ
Đăng nhập rồi có cần check quyền từng API không?
Có. Authentication chỉ chứng minh danh tính. Authorization phải được kiểm ở từng hành động nhạy cảm.
JWT có an toàn hơn session không?
Không mặc định. JWT và session đều an toàn nếu thiết kế đúng, và đều nguy hiểm nếu TTL, revoke, cookie hoặc storage sai.
RBAC có đủ cho SaaS không?
RBAC đủ cho giai đoạn đầu, nhưng khi quyền phụ thuộc ownership, team, region hoặc trạng thái resource, bạn sẽ cần policy/ABAC bổ sung.
Kết luận
Backend an toàn bắt đầu từ việc phân biệt rõ authentication và authorization. Đăng nhập thành công mới là bước đầu; hệ thống production cần policy nhất quán, object-level permission, token/session lifecycle, audit log và test bảo mật lặp lại trong CI.
Nên đọc tiếp: Backend Engineering là gì, Deploy Backend lên Production, REST API Design Checklist.
