RBAC stands for role-based access control. Instead of assigning permissions to each individual user, you assign them to roles — and give users a role.
In the simplest form, every user has a role field. Instead of checking "can this specific user delete notes?", you check "does this user's role allow deleting notes?"
Alice → admin → can delete any note, can view all users
Bob → member → can only see and delete their own notes
You don't need a separate permissions table for this. One column (role) and one check (isAdmin) is enough.
Imagine you have 100 users and you want 5 of them to access the admin dashboard. You could add a can_access_admin flag to each of the 5 users. Then when you want those same 5 to delete notes, you add can_delete_notes. Then can_view_all_users. That's three flags — and the list grows with every feature.
With roles, you set role: 'admin' once. The admin role carries all the permissions. Add a new admin feature and every admin gets it automatically.
RBAC works well when permissions map cleanly to roles. It starts to strain when you need fine-grained rules like "users can only edit documents they own" or "managers can approve requests from their direct reports."
At that point, you might layer in ownership checks (is this the user's own data?) or move to a more expressive system like attribute-based access control (ABAC). But most apps never need that. Start with roles.