Skip to main content
Software Dictionary

Side by side

RBACvsABAC

What is the difference between RBAC and ABAC?

Updated 3 min read8 differences

In short

RBAC grants permissions through roles such as admin or editor; ABAC decides each request from attributes of the user, the resource, the action and the context.

Securityp. 38

RBAC

Role-Based Access Control

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.

Read the page on RBAC
Securityp. 1

ABAC

Attribute-Based Access Control

ABAC is an authorization model that allows or denies each request by checking attributes of the user, the resource, the action and the context against policies.

Read the page on ABAC

RBAC and ABAC compared

AspectRBACABAC
Decides byThe roles a user holdsAttributes of the user, resource, action and environment
Rules live inMappings from roles to permissionsPolicies, evaluated in code or by a policy engine
GranularityCoarse: the same access for everyone in a roleFine: conditions such as ownership, department or time
ContextIgnored unless roles are scoped, for example per projectTime, location, device and other request data can count
AuditingEasy: list each role's permissionsHarder: the answer depends on data at request time
Setup effortLow: define roles and assign themHigher: attribute sources, policies and often an engine
Typical problemRole explosion as special cases add more rolesComplex policies that are hard to review and test
Best forClear job functions and broad permissionsOwnership, multi-tenant data and rules that depend on context

The difference, explained

RBAC, role-based access control, attaches permissions to roles such as viewer, editor and admin and gives users access by assigning them roles. ABAC, attribute-based access control, decides each request by checking policies against attributes of the subject, the resource, the action and the environment, such as a user's department, a document's owner or the time of day. Both are authorization models: they decide what an authenticated user may do.

The difference is the question each one asks. RBAC asks only which roles the user holds, so access is fixed in advance: listing a role's permissions shows who can do what, which makes RBAC easy to understand and audit. ABAC computes the answer at request time from live data, so it can express rules such as "users may edit only their own drafts" or "doctors may read the records of patients in their own department", which plain roles can't.

Each one's cost shows up at scale. Pure RBAC tends toward role explosion, as narrow roles for special cases pile up until nobody can tell who has access to what; ABAC avoids that, but its rules are harder to review because the outcome depends on data. Many systems therefore combine the two: roles for broad access and attributes for fine-grained conditions such as ownership, tenant or country, often evaluated by a policy engine such as Open Policy Agent or Cedar.

A common misconception is that ABAC replaces RBAC. A role is just one attribute among many, so RBAC can be seen as a special case of ABAC, and most ABAC setups still use roles. Another is that the choice is permanent: many applications start with roles and add attribute rules only where roles stop being enough.

Which one should you use?

Choose RBAC when…

  • Access follows clear job functions such as viewer, editor and admin.
  • Auditors need to see quickly who can do what.
  • You want a simple model that is easy to build and explain.
  • Permissions rarely depend on who owns a record or when it is accessed.

Choose ABAC when…

  • Rules depend on data, such as ownership, department or tenant.
  • Context matters: time, location, device or risk level.
  • Roles keep multiplying to cover special cases.
  • You want policies managed centrally in an engine such as Open Policy Agent or Cedar.

A role check vs an attribute-based policy check

RBACtypescript
// RBAC: the decision depends only on the user's roles
const rolePermissions: Record<string, string[]> = {
  viewer: ["doc:read"],
  editor: ["doc:read", "doc:edit"],
};

function canRbac(user: { roles: string[] }, action: string): boolean {
  return user.roles.some((role) => rolePermissions[role]?.includes(`doc:${action}`));
}

canRbac({ roles: ["editor"] }, "edit"); // true, for every document
ABACtypescript
// ABAC: the decision combines attributes of the user, the document and the time
type User = { id: string; department: string };
type Doc = { ownerId: string; department: string; status: "draft" | "published" };

function canAbac(user: User, doc: Doc, action: "read" | "edit", now = new Date()): boolean {
  if (action === "read") return user.department === doc.department;
  const workingHours = now.getHours() >= 8 && now.getHours() < 18;
  return doc.ownerId === user.id && doc.status === "draft" && workingHours;
}

const draft: Doc = { ownerId: "u1", department: "sales", status: "draft" };
canAbac({ id: "u1", department: "sales" }, draft, "edit"); // true only for the owner, in working hours

Readers ask

Is ABAC better than RBAC?

Not in general. ABAC is more flexible and expresses rules that roles can't, but it is harder to build and audit. RBAC is enough for many applications, and many larger systems use roles for broad access and attributes for fine-grained rules.

Can you combine RBAC and ABAC?

Yes, and it is common. The user's role becomes one attribute in an ABAC policy, for example "editors may edit documents in their own department", so roles stay simple while attributes handle the exceptions.

Are RBAC and ABAC authentication or authorization?

Both are authorization. Authentication first confirms who the user is; RBAC or ABAC then decides what that user is allowed to do.

More

Settings

EnglishTürkçe