What is RBAC in one sentence?

RBAC is an authorization model that attaches permissions to roles rather than to people, so you grant access by assigning a user to a role instead of editing dozens of individual permissions.

What is the difference between RBAC and ABAC?

RBAC decides access from a user's role. ABAC decides access from attributes — user, resource, action, and environment — evaluated by a policy at request time, which is more flexible but harder to audit.

What is role explosion?

Role explosion is when an organization creates so many narrowly scoped roles to handle edge cases that the role catalog becomes larger and harder to manage than the per-user permissions RBAC was meant to replace.

Is RBAC the same as least privilege?

No. RBAC is a mechanism; least privilege is a goal. RBAC makes least privilege easier to implement, but a sloppily designed role with too many permissions violates least privilege just as much as a sloppily permissioned user.

Does RBAC work for multi-tenant SaaS?

Yes, but roles usually have to be scoped per tenant so an admin in one customer's workspace cannot act in another's. Most SaaS products combine tenant-scoped RBAC with a small set of platform-level roles.

Glossary · Security

What is Role-Based Access Control (RBAC)?

RBAC is an authorization model that attaches permissions to named roles — like "billing-admin" or "support-readonly" — instead of to individual people. You grant someone access by assigning them to a role, and you revoke it by removing the role, so access is managed in a handful of well-understood buckets rather than one user at a time.

Where it came from

The model was formalized by David Ferraiolo and Richard Kuhn at the US National Institute of Standards and Technology in a 1992 paper, and it became an official standard — INCITS 359 — in 2004. The motivating insight was simple: in any real organization, what someone is allowed to do follows from their job, not from their identity, so you should model permissions around jobs. A new accountant should inherit the accountant permission set on day one rather than have an administrator hand-pick thirty individual grants.

The three moving parts

RBAC has exactly three things to reason about. Permissions are the low-level "can do" facts — read this table, refund this charge, deploy this service. Roles are named bundles of permissions that map to a job function. Assignments connect users to roles. The whole point is that the two ends — people and permissions — never touch directly; everything goes through the role in the middle. That indirection is what makes a quarterly access review tractable: you review a dozen roles, not ten thousand individual grants.

Role hierarchies and constraints

Mature RBAC adds two refinements. Role hierarchies let a senior role inherit a junior role's permissions — a "manager" role automatically gets everything "employee" can do, plus more, so you do not duplicate permission lists. Constraints enforce rules like separation of duties: the person who submits a payment must not be the person who approves it, so the two roles are declared mutually exclusive and no single user can hold both. These two features are what separate a real RBAC implementation from a flat list of permission groups.

Where RBAC breaks: role explosion

RBAC's weakness shows up when access depends on data, not just job function — "a regional manager can edit orders, but only in their own region." Pure RBAC handles this by minting a separate role per region, and then per department, and then per combination, until the role catalog has thousands of entries and is harder to manage than the per-user mess it replaced. This is called role explosion, and it is the standard signal that you have outgrown plain RBAC and need attribute-based rules layered on top — which is exactly what ABAC provides.

At QUANT LAB

Almost every product we build needs an authorization model, and RBAC is usually the right default. In our SaaS platform builds we scope roles per tenant so a customer admin can never act outside their own workspace, and we wire role assignments into the same identity and access management layer that handles login. When we run a penetration test, broken access control — a user reaching a resource their role should not allow — is one of the most common and most damaging findings, so we test role boundaries directly rather than trusting the diagram.

Designing roles that last

The practical advice is to start coarse and resist the urge to create a role for every exception. Model roles on durable job functions, not on individual people or temporary projects. Keep the role count low enough that a human can read the whole catalog in one sitting. When a request genuinely depends on data attributes rather than job function, reach for an attribute rule instead of inventing another role. And review assignments on a schedule — RBAC's auditability is its biggest advantage, but only if someone actually performs the audit.

Long-form deep-dives that use this term

All posts

Related terms

Designing an access model?

We design and test authorization for SaaS platforms and internal tools, then verify the boundaries hold. Book a 30-minute call.

SaaS platform development