Role-based access control (RBAC) grants permissions through user roles or groups. A role represents a permission set, such as admin, doctor, receptionist, driver, or passenger. section 7.7
RBAC protects operations and APIs only when every request checks the caller’s role. Hiding admin paths or assuming that only legitimate users will call them does not enforce authorization. section 1.4 section 4.7
A practical RBAC implementation follows these checks:
- Configure roles and permission sets in the identity provider, then assign roles to users. section 8.6
- Include the user’s roles or permissions in the access-token payload as a custom claim. section 7.7
- Validate the token and check the required role before processing every protected operation. section 7.7 section 8.7
- Use granular access scopes when users need different operation-level permissions that do not fit discrete groups. section 7.7
Protecting an admin endpoint
An admin-only endpoint can validate the bearer token, inspect its permissions claim, and reject requests without the admin permission. A normal user reaching GET /admin/students represents privilege escalation and should receive a denial response.
Figure 4.15 A good strategy to prevent BFLA is to declare user roles explicitly in access tokens and check those roles on every request across all operations.
Shows the core defense: declare roles explicitly in access tokens and check them across every operation. section 4.7
Test RBAC by sending a normal user’s authenticated token to admin endpoints and asserting denial. Also test malformed, expired, or tampered tokens and distinguish role bypass from same-role object access. section 12.1 section 12.4
