A permission is an access privilege: it allows or denies a particular action on a resource. A web API might permit a user to read an endpoint but not update or delete data. Authorization checks those privileges; authentication establishes who the user is so the system can make that check. section 9.1.2
An access control list (ACL) describes which users or groups may perform actions such as reading, writing, or deleting a resource. Anonymous users usually receive only the lowest level of access, such as public content. After login, the system can check the authenticated user’s privileges and decide whether to allow access to restricted resources. section 9.1.2
Permissions for a board-game API
Suppose the API needs three levels of access. Ordinary users have the same permissions as anonymous users. Moderators can use read-only and update endpoints, but cannot delete data or seed the database. Administrators can read, update, delete, and seed. A parameterless [Authorize] attribute checks whether a user is authenticated; by itself, it does not distinguish moderators from administrators. section 9.4
In ASP.NET Core, role-based access control puts those distinctions into practice:
- Create Moderator and Administrator roles, then assign the relevant users to them. Each role acts as a group whose authorization rules apply to its members. section 9.4
- Include each user’s roles as claims in their JWT so the authorization middleware can recognize them. section 9.4
- Set role requirements on the action methods that need moderator or administrator access, rather than relying only on a parameterless [Authorize] attribute. section 9.4
Check the result with users in each role: an authenticated user should not gain administrator access merely by logging in, a moderator should be blocked from deletion and seeding, and an administrator should be allowed to perform both. section 9.4
