Series Authorization Thực chiến #1: AuthN vs AuthZ – Đừng nhầm lẫn giữa "Người gác cổng" và "Luật lệ hoàng cung"

Chào bạn và anh em!

Sau khi đã thiết lập được những hệ thống kiến trúc Backend đồ sộ với Docker, Elasticsearch và Redis, chúng ta bắt buộc phải đối mặt với một bài toán bảo mật sống còn: Quyền truy cập.

Rất nhiều hệ thống bị sập hoặc lộ dữ liệu khách hàng không phải vì hacker quá giỏi, mà vì Backend Engineer thiết kế sai luồng phân quyền. Một API lấy danh sách giao dịch bị lộ ra ngoài, và bất kỳ ai cũng có thể gọi nó để xem dữ liệu của người khác. Đó là thảm họa.

Hôm nay, chúng ta chính thức khởi động series về Authorization (Phân quyền). Ở bài học đầu tiên này, chúng ta sẽ bóc tách hai khái niệm kinh điển nhất nhưng cũng dễ gây nhầm lẫn nhất trong giới lập trình, đồng thời điểm qua những mô hình phân quyền phổ biến nhất hiện nay.

1. AuthN và AuthZ: Hai anh em khác biệt

Trong các tài liệu kỹ thuật tiếng Anh, bạn sẽ thường xuyên bắt gặp từ viết tắt Auth. Nhưng "Auth" thực chất là sự gộp chung của hai quy trình hoàn toàn khác nhau:

• AuthN (Authentication - Xác thực): Giải quyết câu hỏi "BẠN LÀ AI?"
• Đây là bước kiểm tra danh tính. Khi một nhân viên nhà ga nhập Username/Password, hoặc khi hành khách quẹt thẻ từ vào máy đọc, hệ thống đang làm nhiệm vụ AuthN.
• Đầu ra của AuthN: Thường là một Session ID hoặc một chuỗi JSON Web Token (JWT) để chứng minh người này hợp lệ.

AuthZ (Authorization - Phân quyền): Giải quyết câu hỏi "BẠN ĐƯỢC PHÉP LÀM GÌ?"

Đây là bước kiểm tra đặc quyền. Kể cả khi bạn đã chứng minh được mình là ai (AuthN thành công), hệ thống vẫn phải kiểm tra xem bạn có được phép thực hiện hành động hiện tại hay không.

Hãy hình dung thế này: "Người gác cổng" (AuthN) đã kiểm tra thẻ bài và cho phép bạn bước vào cổng thành. Nhưng khi vào trong, "Luật lệ hoàng cung" (AuthZ) sẽ quy định gắt gao rằng: Bạn chỉ là lính canh nên chỉ được đi vòng quanh ngự hoa viên, tuyệt đối không được bước chân vào thư phòng của nhà vua. Nếu cố tình vượt rào, bạn sẽ bị tóm cổ ngay lập tức (Lỗi 403 Forbidden).

Ví dụ thực tế: Một nhân viên bán vé quẹt thẻ đăng nhập vào hệ thống quản lý nhà ga thành công (AuthN). Nhưng khi nhân viên này bấm vào nút "Hoàn tiền vé", hệ thống lập tức báo lỗi. Lý do là vì tài khoản của nhân viên này chỉ có quyền Tạo vé (Create Ticket) chứ không được cấp quyền Hoàn tiền (Refund Ticket) – vốn chỉ dành cho cấp Quản lý.

• Đầu ra của AuthZ: Là một quyết định Allow (Cho phép) hoặc Deny (Từ chối).

Tóm tắt sự khác biệt: Đừng bao giờ nhầm lẫn!

Để anh em dễ nhớ, hãy lưu lại bảng so sánh thần thánh này:

2. Các mô hình Phân quyền (AuthZ) phổ biến hiện nay

Khi hệ thống Backend của bạn phình to, lượng Users và Resource tăng lên chóng mặt, việc code cứng (hardcode) bằng lệnh if (user.role == 'admin') sẽ biến source code thành một mớ bòng bong bảo trì cực kỳ ác mộng. Đó là lúc chúng ta cần áp dụng các mô hình phân quyền chuẩn mực.

Dưới đây là 3 "gương mặt vàng" trong làng Authorization:

1. ACL (Access Control List):

• Đây là dạng cơ bản nhất. Hệ thống duy trì một danh sách ghi rõ User A được đụng vào Resource B.
• Ứng dụng: Rất thích hợp cho các hệ thống nhỏ hoặc quyền sở hữu tài nguyên đơn giản (ví dụ: Google Drive cho phép User A xem file X, User B sửa file Y).

2. RBAC (Role-Based Access Control - Phân quyền theo vai trò):

• Đây là mô hình quốc dân mà 90% các hệ thống từ nhỏ đến lớn đang sử dụng. Thay vì cấp quyền trực tiếp cho User, chúng ta sẽ gán quyền (Permission) cho các Vai trò (Role). Sau đó gán Role cho User.
• Ứng dụng: Hệ thống CMS, quản lý nhân sự, ERP,... (Chúng ta sẽ đào cực sâu vào mô hình này ở bài viết tiếp theo).

3. ABAC (Attribute-Based Access Control - Phân quyền theo thuộc tính):

• Trùm cuối của sự phức tạp và linh hoạt. Mô hình này không chỉ xét Role mà còn xét các thuộc tính ngữ cảnh (Context) như: Vị trí địa lý, thời gian, IP, hoặc trạng thái của dữ liệu.
• Ứng dụng: Hệ thống ngân hàng (chỉ cho chuyển tiền dưới 100 triệu trong giờ hành chính), hệ thống hạ tầng an ninh mạng.

Tổng kết bài 1

Hy vọng qua bài viết này, anh em đã không còn lấn cấn khi đối mặt với cặp bài trùng AuthN và AuthZ. Nắm vững khái niệm là bước đầu tiên để xây dựng một kiến trúc bảo mật vững chắc.

Ở bài viết tiếp theo Series Authorization Thực chiến #2: Thiết kế Database chuẩn RBAC – Xây dựng bộ khung xương sống, chúng ta sẽ chính thức bắt tay vào việc thiết kế cấu trúc các bảng SQL để giải quyết triệt để bài toán phân quyền này. Hẹn gặp lại anh em ở bài sau!