# RBAC vs ABAC

URL: https://softwaredictionary.org/compare/rbac-vs-abac
Last updated: 2026-10-06

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.

## What is the difference between RBAC and ABAC?

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.

| Aspect | RBAC | ABAC |
| --- | --- | --- |
| Decides by | The roles a user holds | Attributes of the user, resource, action and environment |
| Rules live in | Mappings from roles to permissions | Policies, evaluated in code or by a policy engine |
| Granularity | Coarse: the same access for everyone in a role | Fine: conditions such as ownership, department or time |
| Context | Ignored unless roles are scoped, for example per project | Time, location, device and other request data can count |
| Auditing | Easy: list each role's permissions | Harder: the answer depends on data at request time |
| Setup effort | Low: define roles and assign them | Higher: attribute sources, policies and often an engine |
| Typical problem | Role explosion as special cases add more roles | Complex policies that are hard to review and test |
| Best for | Clear job functions and broad permissions | Ownership, multi-tenant data and rules that depend on context |

## 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.

## Frequently asked questions

**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.

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt