Role-based access control (RBAC) is an authorization model that grants permissions based on a user’s assigned role, rather than to individuals directly, an "editor" can do these things, an "admin" those, a "viewer" only these. It’s the most widely used access-control model because it’s simple to understand, manage, and audit.

RBAC organizes access around job functions: define what each role can do, assign users to roles, and permissions follow. This indirection (permissions attached to roles, users attached to roles) is what makes RBAC manageable at organizational scale.

How RBAC works

Administrators define roles (e.g., "support agent," "finance manager"), assign a set of permissions to each role, and then grant users membership in the appropriate roles. A user’s effective permissions are the sum of their roles’ permissions. When someone changes jobs, you change their roles rather than editing dozens of individual permissions, which keeps access aligned to function and simplifies the "who can do what" question for audits.

Strengths of RBAC

RBAC’s appeal is simplicity and governance. It’s easy to reason about, straightforward to audit (roles map to job functions), and efficient to manage for common cases, onboarding a new employee means assigning roles, not hand-picking permissions. It maps naturally to how organizations think about jobs and responsibilities, which is why it’s the default in most enterprise systems.

The limits of RBAC

RBAC struggles as requirements get granular or contextual. If access depends on attributes (department, location, time) or on relationships (this user owns this specific document), pure RBAC leads to "role explosion", creating ever more narrow roles to capture every combination, until the model becomes unwieldy. RBAC also isn’t naturally suited to per-resource, fine-grained decisions. This is why more flexible models (ABAC (attributes) and ReBAC (relationships)) emerged, and why complex systems often combine RBAC with them.

RBAC in practice

For many applications, RBAC is the right, pragmatic choice, simple needs are served simply. The key is recognizing when you’ve outgrown it: when roles proliferate to capture exceptions, when access decisions increasingly depend on context or relationships, or when you need fine-grained control over individual resources. At that point, augmenting RBAC with attribute- or relationship-based models, ideally through a dedicated authorization service, keeps access both flexible and manageable.

Frequently asked questions

What is RBAC?

An access-control model that grants permissions based on a user’s role rather than to individuals directly.

How does RBAC work?

Permissions are assigned to roles, users are assigned to roles, and each user’s access is the sum of their roles’ permissions.

What are the limits of RBAC?

It struggles with attribute- or relationship-based and fine-grained access, leading to "role explosion" as narrow roles multiply.

When should you move beyond RBAC?

When roles proliferate to capture exceptions, or access depends on context, attributes, or per-resource relationships.

What is role explosion?

The proliferation of ever-narrower roles created to capture every access combination, which makes RBAC unwieldy at scale.

Is RBAC still widely used?

Yes, it’s the most common access-control model because it’s simple, auditable, and maps well to job functions, often combined with ABAC or ReBAC for nuance.

What’s a good use case for RBAC?

Organizations with clear job functions and relatively stable, coarse-grained access needs, where roles map cleanly to responsibilities.

Related: Authorization · Attribute-Based Access Control (ABAC) · Relationship-Based Access Control (ReBAC) · Fine-Grained Authorization (FGA) · Principle of Least Privilege