Role-based access control (RBAC) decides whether a request is allowed by assigning users or services named roles, then checking the permissions attached to those roles. A permission is a specific operation such as reading a report, editing a profile, or deleting an invoice. section 17.1.1
RBAC keeps authorization understandable: instead of maintaining a separate permission list for every user, assign an employee, manager, or admin role. The role acts like a security badge, bundling the actions associated with that responsibility. section 17.1.1
A typical RBAC decision follows this pattern:
- Define roles such as employee, manager, and admin. section 17.1.1
- Attach permissions to each role, such as viewing profiles, editing team reports, or accessing everything. section 17.1.1
- Assign one or more roles to a user or service. section 17.1.1
- Check the role when the request reaches the protected resource; deny access when no assigned role permits the action. section 17.1.1
Protecting an administrator endpoint
A token might contain {"sub":"alice","roles":["manager"]}. A Spring Security endpoint can then require the administrator role with @PreAuthorize("hasRole('ADMIN')"). Alice’s manager role does not satisfy that check, so the dashboard remains protected. section 17.1.1
RBAC is easy to implement, widely supported, and fast to evaluate. Its limits appear when access depends on department, region, project, time, or ownership rather than a fixed role. Teams may respond by creating roles such as invoice_approver_eu or contract_editor_fr, producing role explosion: excessive, unclear roles that are difficult to manage and audit. section 17.1.1 section 17.3
In a monolith, authorization can use local user and resource data, but scattered checks become a maintenance risk. In service-oriented systems, each service must enforce authorization independently; shared role meanings and trustworthy identity propagation are essential because an upstream check is not enough. section 17.2.1 section 17.2.2
{
"sub": "user567",
"tenant_id": "megamart", #1
"role": "inventory_manager",
"permissions": ["view_reports", "manage_suppliers"]
}
A tenant-aware token can carry tenant identity, a tenant-specific role, and permissions, allowing separate organizations to define their own authorization rules. section 13.4
