Back to all terms
UserRoleReadWriteUserAdminDelete
Authbasic

RBAC (Role-Based Access Control)

An access control model where permissions are assigned to roles, and users are granted roles, simplifying permission management at scale.

Also known as: Role-Based Access Control, RBAC, Role-Based Permissions

Description

Role-Based Access Control (RBAC) is an authorization model that restricts system access based on the roles assigned to individual users within an organization. Rather than assigning permissions directly to users, permissions are grouped into roles (e.g., admin, editor, viewer), and users are assigned one or more roles. This indirection simplifies permission management -- when a new permission is needed, it is added to the role rather than to each individual user.

RBAC implementations range from flat models (users have roles, roles have permissions) to hierarchical models where roles can inherit permissions from parent roles (e.g., admin inherits all editor permissions, which inherits all viewer permissions). The NIST RBAC standard defines four levels: Core RBAC (users, roles, permissions, sessions), Hierarchical RBAC (role inheritance), Static Separation of Duty (mutually exclusive role assignments), and Dynamic Separation of Duty (mutually exclusive role activations within a session).

In practice, RBAC is implemented by storing role assignments in a database, including role information in JWT claims or session data, and checking permissions in middleware or authorization guards before processing requests. For microservices, role and permission data is typically embedded in the access token to avoid cross-service lookups. RBAC works well for organizations with well-defined role structures but can lead to role explosion in complex scenarios, which is where ABAC becomes a better fit.

Prompt Snippet

Implement RBAC with a database schema containing users, roles, permissions, and join tables (user_roles, role_permissions). Define roles like admin, editor, viewer with hierarchical inheritance. Embed role and permission arrays in JWT access token claims. Create an authorization middleware that extracts roles from the JWT, resolves effective permissions (including inherited), and checks against the required permission for the endpoint. Use a decorator/annotation pattern like @RequiresPermission('posts:write') for route-level enforcement. Cache role-permission mappings in Redis with cache invalidation on role updates.

Tags

rbacrolespermissionsauthorizationaccess-control