RBAC vs. ABAC: Choosing and Combining Authorization Models

As a design rule of thumb, start with RBAC when permissions follow stable job responsibilities. Consider ABAC when decisions depend on resource properties or contextual conditions. Combine them when a role establishes eligibility but additional restrictions must govern each operation. Treat this as a policy-design choice—not a shortcut to security or a prediction of performance.

What RBAC and ABAC actually decide

Role-based access control, or RBAC, assigns users to roles and privileges to those roles. An application might give an invoice_approver role permission to approve invoices. NIST’s archived RBAC overview describes this organizational approach and explicitly discusses role hierarchies and mutually exclusive roles. RBAC is therefore not necessarily a flat list of unconstrained permission bundles. NIST RBAC overview

Attribute-based access control, or ABAC, evaluates attributes associated with the subject, object, requested operation, and sometimes the environment against a policy. An invoice-approval policy could consider the requester’s approval limit, the invoice amount, and the invoice’s tenant. These are examples of the attribute categories in NIST’s definition, not requirements of every ABAC implementation. NIST SP 800-162

The distinction is not simply “roles versus rules,” nor must implementations keep them separate: OWASP lists job role among the possible attributes used in ABAC. OWASP Authorization Cheat Sheet

Ask instead: Which access decisions belong in reusable job permissions, and which require information about this particular request?

RBAC: organize permissions around responsibilities

For an illustrative billing application, begin with three roles:

• invoice_reader: view invoices.
• invoice_editor: create and modify invoices.
• invoice_approver: approve invoices.

This gives an access review a concrete starting point: what does each role permit, and who should hold it? That structure follows NIST’s description of identifying operations associated with jobs and assigning people to the appropriate roles. NIST RBAC overview

Now introduce regional scope, tenant boundaries, approval limits, and temporary exceptions. One possible design creates roles such as tenant_a_eu_approver_under_1000. Repeating that naming pattern for every combination produces a larger catalog to maintain.

Treat this as a modeling warning, not proof that RBAC inevitably causes role proliferation. Before creating another role, ask whether it represents a distinct responsibility or merely packages several independent restrictions together.

Also make scope explicit. In this example, holding an approver role for one tenant should not authorize approvals for another tenant. Review inherited permissions and exceptional grants alongside direct assignments; do not make the review depend only on a role’s name.

ABAC: define the inputs as carefully as the policy

An attribute-based version of the example might require the invoice’s tenant to match an authorized tenant and its amount to fall within the requester’s approval limit. Rather than naming a role for each limit, the policy compares values.

For this design, document an attribute contract before implementing the evaluator:

Input	Questions to resolve
Tenant membership	Which system is authoritative? Is membership active? Who may change it?
Approval limit	Who may change it? Is it scoped to the tenant and currency?
Invoice amount	Which stored value is authoritative at approval time? Who may modify it?
Invoice creator	Is the identifier trustworthy and protected from changes that would defeat the self-approval check?
Contextual condition	Who supplies it, and what happens when it is unavailable?

These questions turn “use attributes” into an implementable design. NIST defines ABAC in terms of evaluating attributes against policy; the application still needs to specify the meaning and permitted use of its particular inputs. NIST SP 800-162

OWASP recommends denying access by default. Apply that principle to this example by treating missing, invalid, or insufficiently fresh required inputs as a denial. Define freshness requirements for each input rather than leaving “fresh” unspecified. Do not silently substitute an unrestricted approval limit or accept a caller-supplied tenant assertion as authoritative. OWASP Authorization Cheat Sheet

Combine role eligibility with mandatory restrictions

For this invoice workflow, use the role to answer “Does this person perform approvals?” and attributes to answer “May they approve this invoice?”

Here is an illustrative policy specification, not executable code:

Allow invoice approval only when all conditions hold:
  The actor has the invoice_approver role for the invoice's tenant.
  The actor has active membership in that tenant.
  The invoice amount is within the actor's tenant-specific limit,
    using the same currency and amount representation.
  The actor is not the invoice creator.
  Every required authorization input is valid and sufficiently fresh.

The important word is all. Do not turn mandatory restrictions into alternative permission paths. A rule equivalent to “has the approver role OR is within the limit” would permit the role branch to bypass the limit.

Keep the composition visible during review: eligibility, tenant boundary, monetary restriction, and the prohibition on self-approval should each have an identifiable purpose and test case. This example combines the two approaches without asserting that either model requires this particular implementation.

Evaluate enforcement and revocation separately

A successful login is not, by itself, permission to approve an invoice. OWASP notes that authenticated users are not necessarily authorized and can exploit authorization weaknesses. OWASP Authorization Cheat Sheet

For either design, enforce the approval policy on the server-side operation rather than relying on whether the interface displays an approval button. Define how the operation handles changes between the authorization check and the approval being committed—for example, an increase in the invoice amount.

Then trace permission changes through the implementation:

• Where are role memberships and attributes read?
• Are authorization inputs copied into tokens or caches?
• What invalidates those copies?
• How quickly must a revoked membership or reduced limit affect requests?
• What happens when a required dependency is unavailable?

Set an explicit revocation target and test it. Do not assume that evaluating an attribute on each request also means retrieving a fresh value on each request.

For auditability, plan how to explain a decision: identify the applicable policy version and the role assignments or attribute inputs relevant to the result. Retain only the detail needed for that purpose, with appropriate protection for sensitive information.

Choose using a representative policy and test suite

Before committing to a model, implement one realistic operation and test more than its successful path. For invoice approval, include:

• A valid approval that satisfies every required condition.
• An approver acting across a tenant boundary.
• A user with a revoked membership.
• An invoice above the approval limit.
• A missing approval limit or unavailable attribute source.
• An attempted self-approval.
• A policy or approval-limit change while requests are in progress.
• An invoice amount changed between the authorization check and the approval being committed.

Benchmark the proposed implementations rather than assuming an RBAC or ABAC speed advantage. Include allowed and denied requests, cold and warm caches, tail latency, and dependency failures.

Choose the smallest design that expresses the required policy clearly. Prefer role assignments for stable responsibilities; introduce attributes for restrictions that genuinely vary by resource or request. When both are necessary, make their composition explicit—and test the enforcement behavior, not just the policy vocabulary.