Role-Based Access Control (RBAC)
Everything you need to understand, implement, and scale RBAC in a multi-tenant SaaS application. From basic concepts to advanced patterns — with code examples throughout.
On this page
What is RBAC?
Role-Based Access Control (RBAC) is an authorization model where permissions are granted to roles, and roles are assigned to subjects (users, services, or API keys). Instead of attaching permissions directly to individuals, RBAC groups permissions into job-function-based roles — making access policies auditable, manageable, and scalable.
RBAC was formalized by NIST in the INCITS 359 standard and is the most widely deployed authorization model in enterprise software. It is the foundation of access control in databases (PostgreSQL, MySQL), cloud providers (AWS IAM, GCP IAM), and SaaS platforms (GitHub, Slack, Notion).
Key insight
RBAC answers one question: "Does any role assigned to this subject contain a permission that matches this resource + action?"
The core RBAC model
RBAC is a three-hop graph: Subject → Role → Permission → (Resource + Action). A user is assigned one or more roles. Each role bundles a set of permissions. Each permission specifies what action can be performed on what resource, with an effect (allow or deny).
Subject: Alice
└── Role: billing-admin
├── Permission: invoice:* → allow
├── Permission: report:export → allow
└── Permission: invoice:delete → deny (deny-wins carve-out)When Alice attempts to delete an invoice, the system collects all permissions from all her roles, matches them against the requested resource+action (including wildcards), and — with deny-wins semantics — finds the explicit deny on invoice:delete and returns DENIED.
RBAC vs ABAC vs ReBAC
| Dimension | RBAC | ABAC | ReBAC |
|---|---|---|---|
| Model | Subject → Role → Permission | Attributes + Policy Rules | Graph of relationship tuples |
| Best question | "What job function do they have?" | "Do attributes satisfy this policy?" | "How is this subject related to this object?" |
| Context awareness | Identity only | Full (time, location, risk) | Relationship-based |
| Auditability | High — static, queryable | Lower — requires policy simulation | Requires graph queries |
| Operational cost | Low | Medium — attribute sourcing | Higher — tuple store + traversal engine |
Most teams should start with RBAC and layer on ABAC or ReBAC only when the use case demands it. WardenAuth supports all three — RBAC as the foundation, ABAC conditions on any permission, and ReBAC via relationship tuples.
Multi-tenant RBAC architecture
In B2B SaaS, each customer is a scope — an isolated RBAC universe. A user who is "Admin" in Tenant A is "Viewer" in Tenant B. The scope serves as a hard isolation boundary: permissions, roles, and policies in one scope cannot affect another.
Isolation by construction
Every access check requires a scopeId parameter. This is never optional and never inferred from context — preventing cross-tenant data leaks.
Preventing role explosion
Role explosion happens when data dimensions (regions, dollar thresholds, ownership) get encoded into role names. Instead of creating manager-us-east-under-10k, use resource-scoped permissions with wildcards, additive multi-role assignments, and promote runtime data dimensions to ABAC conditions.
Externalized authorization
Externalized authorization separates the Policy Enforcement Point (PEP) — thin code in your app that asks "is this allowed?" — from the Policy Decision Point (PDP) — a dedicated service that owns the rules. Your application stops knowing the rules and starts asking for decisions.
Deep dives & tutorials
RBAC vs. ABAC: Choosing an Authorization Model
Side-by-side comparison with scalability, latency, and auditability tradeoffs.
How to Prevent Role Explosion in RBAC
Three techniques to keep RBAC maintainable at scale.
Externalized Authorization
Why access logic doesn't belong in your application code.
ReBAC vs. RBAC
When relationship-based access control is necessary.
Permission Schema Design
resource:action naming, granularity, wildcards, and deny-wins.
Least Privilege Without Friction
Default-deny, just-in-time elevation, and audit-driven right-sizing.
Multi-Tenant Authorization Patterns
Scope-per-tenant, shared vs per-tenant roles, and cross-tenant support access.
Zero Trust Authorization
Authorization as the enforcement layer of zero trust architecture.
Ready to implement RBAC?
Start free — 50,000 checks/month. Unlimited scopes. SDKs in TypeScript, Go, and Python.
Get started