RBAC

Role-Based Access Control

Pronunciation: AR-back or ar-bee-ay-SEE

Updated September 30, 20262 min read

In short

RBAC is an authorization model that grants permissions to roles, such as admin or editor, and then gives users access by assigning them those roles.

What is RBAC?

RBAC, or role-based access control, is a way of deciding what each user is allowed to do. Instead of attaching permissions directly to individual people, you define roles such as viewer, editor, and admin, give each role a set of permissions, and assign roles to users. When someone changes jobs, you change their role rather than editing dozens of individual permissions.

When a request arrives, the application first authenticates the user, then looks up the roles they hold and checks whether any of those roles includes the required permission, such as invoice:delete. Roles can be scoped, for example admin of one project but viewer of another, and some systems support role hierarchies where a senior role inherits the permissions of a junior one. Good RBAC designs follow the principle of least privilege, giving each role only the permissions it really needs.

Think of a hospital where nurses, doctors, and receptionists each carry a badge type that opens certain doors and records. The hospital doesn't decide door by door for every employee; it decides once per badge type. RBAC is used the same way in business applications, databases, cloud platforms, and container orchestrators like Kubernetes.

RBAC is often compared with ABAC, attribute-based access control. RBAC asks which role the user has, while ABAC evaluates attributes of the user, the resource, and the context, such as department, document owner, or time of day. RBAC is simpler to understand and audit, but large organizations can end up with too many narrowly defined roles, a problem called role explosion.

Key takeaways

Permissions are attached to roles, and users get permissions by being assigned roles.
RBAC is a form of authorization, which happens after authentication.
Least privilege means giving each role only the permissions it needs.
Changing a user's access usually means changing their role, not individual permissions.
ABAC adds attribute-based rules when roles alone are not fine-grained enough.

Example

Checking permissions through rolestypescript

// Each role maps to a set of permissions
const rolePermissions: Record<string, string[]> = {
  viewer: ["invoice:read"],
  editor: ["invoice:read", "invoice:update"],
  admin: ["invoice:read", "invoice:update", "invoice:delete"],
};

function can(userRoles: string[], permission: string): boolean {
  return userRoles.some((role) => rolePermissions[role]?.includes(permission));
}

console.log(can(["editor"], "invoice:update")); // true
console.log(can(["viewer"], "invoice:delete")); // false

Readers ask

What is the difference between RBAC and ABAC?

RBAC grants access based on the roles a user holds, such as admin or editor. ABAC, attribute-based access control, decides using attributes of the user, the resource, and the context, like department or time of day, which is more flexible but harder to manage.

Is RBAC authentication or authorization?

RBAC is authorization. Authentication first confirms who the user is, and RBAC then decides what that user is allowed to do based on their roles.

What is role explosion?

Role explosion happens when an organization keeps creating narrow roles for special cases until there are hundreds of them and nobody can tell who has access to what. Regular access reviews and combining RBAC with attribute-based rules help avoid it.