Key points
- RBAC trades fine-grained precision for operational simplicity — the right default for most apps.
- Common pitfall: role explosion, where every edge case spawns a new role until the model is unmanageable.
- RBAC is often combined with attribute checks (department, region) — at that point you're really using ABAC.
- For relationship-heavy data (docs, projects, tenants), ReBAC scales better.
- Roles should be granted via [IGA](/glossary/iga) processes with periodic access reviews.
What is RBAC?
Role-Based Access Control assigns permissions to roles (Admin, Editor, Viewer, Finance Manager, Support Agent) and then assigns users to roles. Permissions never attach to a user directly. When Alice joins the support team she gets the Support Agent role and inherits everything that role allows; when she moves to engineering you swap her role and her access changes accordingly.
RBAC was formalized by NIST in the 1990s (INCITS 359). It's the default authorization model in almost every operating system, database, and SaaS app you've ever used.
When RBAC is the right call
RBAC works well when:
- Your access decisions cluster cleanly around job function.
- The number of distinct permission bundles is small and stable (dozens, not thousands).
- You need fast, auditable answers to "who can do what?"
- Your auditors want to see access certified by role owner, not user-by-user.
It works badly when:
- Permissions depend heavily on relationships — "can Alice edit this specific document?" — that's ReBAC territory.
- Permissions depend on dynamic attributes — time of day, location, device trust, customer tier — that's ABAC.
- Edge cases keep spawning new roles until you have hundreds.
Most real systems end up as RBAC + a few attribute checks, which is a pragmatic hybrid.
Role explosion
The single biggest failure mode. A team starts with five roles, then adds a "Finance Manager — EMEA" role, then "Finance Manager — EMEA — Read Only," then "Finance Manager — EMEA — Read Only — Excluding Acquisitions," and within a year nobody can explain what any of them actually grant.
Mitigations:
- Use groups + roles — combine static group membership with role assignment instead of encoding everything in role names.
- Move dynamic conditions out of roles and into ABAC policies.
- Use role mining tools (most IGA platforms have one) to collapse overlapping roles.
- Periodic access reviews to retire roles nobody is using.
When buyers care about RBAC tooling
You need a dedicated authorization layer when:
- Your app has more than a handful of permissions and you're tired of
if (user.role === 'admin')checks scattered through the code. - You need to expose role management to customers (multi-tenant SaaS).
- You need to externalize policy from code for auditability and faster iteration.
Look at categories like fine-grained authorization (FGA), policy engines (OPA, Cedar), and full authorization platforms (Auth0 FGA, SpiceDB, Permit, Cerbos, Oso).
FAQ
RBAC or ABAC?
Start with RBAC. Layer ABAC checks (department, location, time) on top when needed. Reach for full ABAC only when most of your decisions are attribute-driven.
Is "least privilege" the same as RBAC?
No. Least privilege is the principle that users should have only the access they need. RBAC is a model that can implement least privilege — or violate it badly, if roles are bloated.