Role-Based Access Control (RBAC)
Term 14 of 68 in the ERPStack technical glossary
What is Role-Based Access Control (RBAC)?
Role-Based Access Control (RBAC) is an authorization mechanism that restricts system access and database operations to authorized users based on their assigned organizational roles rather than individual user accounts.
Role-Based Access Control (RBAC) at a glance
- Model
- 3 layers: users hold roles, roles hold permissions, permissions gate operations
- Granularity
- Permission per operation, not per screen — 1 API route can be reached by 3 different interfaces
- Database pairing
- Row-Level Security in PostgreSQL 18 answers 'which rows', RBAC answers 'which actions'
- Audit expectation
- Every role change recorded, because reviewers test the 2 questions: who granted it and when
- Built with
- RBAC checks in Next.js 16 server actions, roles in PostgreSQL 18 via Drizzle ORM 0.45, input validated by Zod 4, SSO and JWT in front, Row-Level Security below, changes logged for SOC 2
- Numbers that matter
- 3 layers — user, role, permission; 1 break-glass account used rarely; 2 audit questions, who granted it and when; 0 checks left in the interface only
- Compare with
- Per-user grants, and attribute-based schemes evaluated per request
- Commonly paired with
- SSO, JWT sessions, OAuth flows, Row-Level Security in PostgreSQL 18, Next.js 16 server actions and SOC 2 or ISO 27001 access reviews
- Role count
- 12 roles stays readable; 200 is the signal that the model needs scoping or attributes. Review the count each quarter beside the joiner-mover-leaver list.
- Where reviewers look
- healthcare, finance and government systems, where the role list and the Postgres grants underneath it have to tell the same story.
How Role-Based Access Control (RBAC) works in production
The ERPStack approach to Role-Based Access Control (RBAC)
We design secure RBAC middlewares in Next.js, validating user roles against JWT claims at the edge to restrict API routes and dashboard views.
Frequently asked questions about Role-Based Access Control (RBAC)
What does Role-Based Access Control give you over per-user permissions?
Reviewability. Access Control assigned directly to individuals produces a grid nobody can audit, because every person is a special case. Grouping permissions into roles means a reviewer inspects a handful of role definitions and a membership list instead of hundreds of individual grants. It also makes joining, moving and leaving into 1 operation each, rather than a checklist that is completed inconsistently.
Where should permission checks live?
At the operation, not the interface. Hiding a button is presentation; Access Control must be enforced in the API route or server action that performs the work, because the same operation is reachable from a mobile client, a script or a direct request. ERPStack checks at the server boundary and treats the interface as a convenience layer that reflects the decision rather than making it.
How does RBAC differ from attribute-based access control?
By what the decision reads. Role-Based Access Control resolves from role membership, which is simple to reason about and easy to audit. Attribute-based schemes evaluate contextual facts — department, record owner, time of day — which is more expressive and considerably harder to review. Most business systems are best served by roles for the coarse decision plus Row-Level Security for the data boundary.
What are the common RBAC mistakes?
Two recur. The first is roles that mirror job titles rather than operations, so a reorganisation invalidates the entire model. The second is a super-administrator role used for daily work, which makes Access Control unauditable because every action is permitted. Roles built from the operations the system actually exposes, plus a rarely used break-glass account, avoid both.