Authorization — mô hình RBAC

Các trang trước giải thích cách xác định "người dùng này là ai" (authentication). Trang này trả lời câu hỏi còn lại — "người dùng đó được phép làm gì" (authorization) — chính là điều Checklist liên tục nhắc tới nhưng chưa nói rõ cơ chế.

Mô hình phổ biến nhất là RBAC (Role-Based Access Control):

Người dùng (User) → Vai trò (Role) → Quyền hạn (Permission) → Tài nguyên (Resource)

Thay vì gán quyền trực tiếp cho từng người dùng, hệ thống gán người dùng vào một hoặc nhiều vai trò (ví dụ admin, editor, viewer), mỗi vai trò đi kèm một tập quyền hạn cố định (ví dụ editor được tạo/sửa bài viết nhưng không được xoá người dùng). Khi cần kiểm tra quyền, hệ thống chỉ cần hỏi "vai trò của người này có quyền X không?" thay vì quản lý quyền rời rạc cho từng cá nhân.

Nguyên tắc thiết kế RBAC đúng cách:

• Deny-by-default (từ chối theo mặc định): mọi hành động đều bị từ chối trừ khi có quyền được cấp rõ ràng — không thiết kế theo kiểu "cho phép mọi thứ trừ khi bị cấm".
• Nguyên tắc đặc quyền tối thiểu (least privilege): mỗi vai trò chỉ nên có đúng quyền cần thiết để hoàn thành công việc, không hơn.
• Phân cấp vai trò (role hierarchy): ví dụ admin kế thừa toàn bộ quyền của editor, editor kế thừa quyền của viewer — tránh phải khai báo trùng lặp quyền ở nhiều vai trò.
• Kiểm tra ở tầng server, trên từng request: việc kiểm tra vai trò/quyền phải nằm trong middleware hoặc logic xử lý ở backend, áp dụng cho từng endpoint, không được suy luận từ dữ liệu client tự gửi lên.

Với hệ thống cần độ chi tiết cao hơn RBAC (ví dụ quyền phụ thuộc vào thuộc tính của chính đối tượng dữ liệu, như "chỉ được sửa bài viết do chính mình tạo"), mô hình mở rộng thường gặp là ABAC (Attribute-Based Access Control) — quyết định quyền dựa trên thuộc tính (attribute) của người dùng, tài nguyên, và ngữ cảnh, thay vì chỉ dựa vào vai trò cố định. RBAC nên là điểm khởi đầu mặc định; chỉ cân nhắc ABAC khi RBAC thực sự không đủ biểu đạt.