Xác thực (authentication) khác phân quyền (authorization) thế nào? Nên kiểm tra quyền ở đâu trong một ứng dụng web?

Xác thực trả lời câu hỏi "bạn là ai", ví dụ đăng nhập bằng email và mật khẩu. Phân quyền trả lời câu hỏi "bạn được làm gì", ví dụ chỉ tác giả được sửa bài. Hai việc này tách rời nhau, và lỗi hay gặp nhất là coi việc thứ nhất như đã bao gồm việc thứ hai.

Ví dụ cụ thể: một blog viết luật "ai đã đăng nhập thì được sửa bài", vì nghĩ rằng chỉ có tác giả mới có tài khoản. Nếu dịch vụ đăng nhập còn cho phép tự đăng ký, bất kỳ ai cũng tạo được tài khoản, đăng nhập hợp lệ, và sửa được bài. Người đó đã được xác thực đúng, nhưng chưa từng được phân quyền.

Về chỗ kiểm tra quyền, câu trả lời tốt nêu được ba tầng và vai trò của từng tầng:

1. Giao diện (ẩn nút, chuyển hướng): chỉ để người dùng thấy đúng thứ họ dùng được. Không bảo vệ gì, vì người ta gọi thẳng API.
2. Server (API route, Server Action, middleware): mỗi điểm nhận request phải tự kiểm tra lại, không dựa vào việc người dùng đã đi qua trang nào.
3. Database (ví dụ Row Level Security của PostgreSQL): lớp cuối cùng, vẫn đúng khi tầng trên viết thiếu một chỗ kiểm tra.

Thêm hai ý cho thấy bạn đã làm thật:

• Thông tin dùng để phân quyền phải nằm ở nơi người dùng không tự sửa được. Với Supabase, đó là app_metadata chứ không phải user_metadata.
• Ở phía server, phải kiểm tra chữ ký của token chứ không chỉ đọc cookie, vì người dùng tự đặt được cookie trong trình duyệt của họ.

Điểm cộng: nhắc tới mã 401 (chưa xác thực) và 403 (đã xác thực nhưng không có quyền), và việc quyền mới cấp hoặc mới thu hồi chỉ có hiệu lực khi token được làm mới.