Choosing Between RBAC and ABAC

Picking the wrong authorization model is one of the most expensive architecture mistakes a platform can make: it surfaces as OWASP A01:2021 Broken Access Control, ships brittle permission checks scattered across services, and forces a painful rewrite once the role list crosses three digits. This guide — part of the Advanced Access Control & Authorization reference — frames the choice between Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) as a concrete engineering decision rather than a religious one. You will model both, compare them against a decision matrix, and see where a hybrid that treats roles as just another attribute outperforms either pure model.

Prerequisites

Before you can choose well, lock down the layer underneath the decision:

• Verified identity. Your authentication layer must issue cryptographically signed tokens (RS256/ES256) with strict exp, nbf, iss, and aud claims (RFC 7519). Authorization that trusts unverified claims is theater.
• A normalized subject model. Whatever you choose, you need one canonical representation of the principal — user id, tenant id, group memberships — resolved server-side from authoritative directories, never from request bodies.
• An inventory of protected actions. Enumerate the resource/action pairs you actually guard (invoice:read, invoice:approve, report:export). You cannot size a role catalog or a policy set without it.
• Latency and audit SLAs. Know your p95 budget for an authorization decision and your compliance requirements (SOC 2, ISO 27001, OWASP ASVS V4 access-control controls). These constraints, more than taste, decide the model.

Problem framing: two ways to answer “can this principal do this?”

Every authorization system answers the same question — is subject allowed to perform action on resource in environment? RBAC and ABAC differ in how they encode the answer.

RBAC is an indirection table. You assign principals to roles, and roles to permissions. The decision is a set-membership test: does the union of the user’s roles include the required permission? It is fast, trivially auditable (“who has billing_admin?”), and intuitive to non-engineers. Its failure mode is role explosion — every new combination of tenant, region, project, and clearance spawns a new role, until the catalog is unmanageable.

ABAC is a policy evaluation. You write rules over attributes of the subject, resource, action, and environment, and a policy engine evaluates them per request. It expresses context that RBAC cannot — “owners can edit their own documents during business hours from a trusted network.” Its failure mode is policy explosion plus opacity: answering “who can edit invoice 42?” may require simulating every policy against every principal, because no static grant exists to query.

The RBAC design problem and the ABAC design problem are deep enough to own dedicated guides; this page is about the boundary between them. The deeper mechanics live in Designing Role-Based Access Control Systems and Implementing Attribute-Based Access Control.

The two evaluation models, side by side

The diagram below contrasts the data flow. RBAC resolves a static grant table; ABAC evaluates dynamic context through a policy decision point.

Step 1 — Model the RBAC answer

In RBAC you precompute the principal’s flattened permission set, then test membership. Resolve roles to permissions server-side; never trust a permissions array a client sends.

// rbac.ts — flatten roles to a permission set, then test membership.
type Permission = `${string}:${string}`; // e.g. "invoice:approve"

interface RoleCatalog {
  // role name -> permissions it grants directly
  [role: string]: Permission[];
}

const catalog: RoleCatalog = {
  viewer: ["invoice:read", "report:read"],
  accountant: ["invoice:read", "invoice:create", "report:read"],
  billing_admin: ["invoice:read", "invoice:create", "invoice:approve", "report:export"],
};

/** Resolve the union of permissions across all of a subject's roles. */
export function resolvePermissions(roles: string[]): Set<Permission> {
  const granted = new Set<Permission>();
  for (const role of roles) {
    for (const perm of catalog[role] ?? []) granted.add(perm);
  }
  return granted;
}

/** The decision is pure set membership — O(1) after resolution. */
export function rbacAllows(roles: string[], required: Permission): boolean {
  return resolvePermissions(roles).has(required);
}

// rbacAllows(["accountant"], "invoice:approve") -> false
// rbacAllows(["billing_admin"], "invoice:approve") -> true

RBAC’s strength is exactly what this code shows: the decision carries no context. invoice:approve is allowed or it is not, regardless of which invoice, the time of day, or the requester’s network. When the answer genuinely depends only on the principal’s job function, that simplicity is a feature, and you should not reach for anything heavier.

Step 2 — Model the ABAC answer

ABAC moves the decision into a policy that reads attributes at evaluation time. Real deployments externalize this to an engine (Cedar, OPA/Rego, Cerbos), but the shape is clearest in plain TypeScript first.

// abac.ts — evaluate a policy over subject/resource/action/environment.
interface Subject { id: string; tenantId: string; roles: string[]; clearance: number }
interface Resource { id: string; ownerId: string; tenantId: string; classification: number }
interface Environment { mfaVerified: boolean; ip: string; hourUtc: number }

interface AccessRequest {
  subject: Subject;
  resource: Resource;
  action: "read" | "edit" | "approve";
  environment: Environment;
}

/** Default-deny: a request is allowed only if at least one rule grants it. */
export function abacAllows(req: AccessRequest): boolean {
  const { subject, resource, action, environment } = req;

  // Hard tenant isolation — evaluated first, short-circuits cross-tenant access.
  if (subject.tenantId !== resource.tenantId) return false;

  // Rule: owners may edit their own resource, but only with MFA.
  if (action === "edit" && resource.ownerId === subject.id) {
    return environment.mfaVerified;
  }

  // Rule: approving high-classification resources needs clearance + business hours.
  if (action === "approve") {
    const businessHours = environment.hourUtc >= 8 && environment.hourUtc < 18;
    return subject.clearance >= resource.classification && businessHours;
  }

  // Rule: reads allowed within tenant for anyone holding a viewer-grade role.
  if (action === "read") {
    return subject.roles.some((r) => ["viewer", "accountant", "billing_admin"].includes(r));
  }

  return false; // implicit deny
}

Notice that the very first roles.includes(...) check inside the read rule is RBAC living inside ABAC — proof that the models are not exclusive. The ABAC engine can read a roles attribute exactly like any other. That observation is the basis of the hybrid model below, and it is why externalizing these rules into a versioned policy decision point in microservices is the natural next step once policies grow past a handful of conditions.

Step 3 — The hybrid: roles as attributes

Most mature systems are neither pure RBAC nor pure ABAC. They use roles as a coarse-grained attribute that gates the cheap, common case, and policies for the contextual minority of decisions. This contains both explosions: the role catalog stays small because it no longer encodes context, and the policy set stays small because routine “job function” checks remain plain role membership.

// hybrid.ts — RBAC fast path, ABAC for contextual exceptions.
import { rbacAllows } from "./rbac";
import { abacAllows, type AccessRequest } from "./abac";

const CONTEXTUAL_ACTIONS = new Set(["approve", "export", "edit"]);

export function hybridAllows(req: AccessRequest, requiredPerm: `${string}:${string}`): boolean {
  // Cheap, cacheable coarse gate: does the role grant the base capability at all?
  if (!rbacAllows(req.subject.roles, requiredPerm)) return false;

  // Routine actions stop here; contextual ones must also satisfy the policy.
  if (!CONTEXTUAL_ACTIONS.has(req.action)) return true;

  return abacAllows(req);
}

This is the pattern to default to. A relationship-centric variant — where the deciding attribute is “is this user related to this resource” — is its own model worth knowing; see Relationship-Based Access Control with OpenFGA when ownership, sharing, and nesting dominate your access rules.

Decision matrix

Use this table as the actual decision aid. Score your system row by row; a clear lean across most rows tells you the model.

Validation & testing

Authorization is the one place where “it seems to work” is a security incident waiting to happen. Test the decision function, not the UI.

// authz.test.ts — exhaustively assert allow AND deny outcomes.
import { describe, it, expect } from "vitest";
import { hybridAllows } from "./hybrid";

const base = {
  subject: { id: "u1", tenantId: "t1", roles: ["billing_admin"], clearance: 3 },
  resource: { id: "inv42", ownerId: "u9", tenantId: "t1", classification: 2 },
  environment: { mfaVerified: true, ip: "10.0.0.1", hourUtc: 12 },
} as const;

describe("hybrid authorization", () => {
  it("denies cross-tenant approval even with the right role", () => {
    const req = { ...base, action: "approve" as const, resource: { ...base.resource, tenantId: "t2" } };
    expect(hybridAllows(req, "invoice:approve")).toBe(false); // tenant isolation wins
  });

  it("denies approval outside business hours", () => {
    const req = { ...base, action: "approve" as const, environment: { ...base.environment, hourUtc: 22 } };
    expect(hybridAllows(req, "invoice:approve")).toBe(false);
  });

  it("allows a routine read on the role gate alone", () => {
    expect(hybridAllows({ ...base, action: "read" as const }, "invoice:read")).toBe(true);
  });
});

Always assert the negative cases. A test suite that only proves the happy path will pass while a default-allow bug ships. For the SQL side of role resolution, the recursive-CTE patterns in How to Structure RBAC Tables in PostgreSQL are the validation target for inheritance correctness.

Common misconfigurations

Security implications

The model you pick reshapes your threat surface. Pure RBAC’s primary risk is privilege creep through role accumulation: users gather roles over their tenure and never shed them, so the flattened permission set silently widens. Mitigate with time-bound assignments and periodic access certification. RBAC also tempts teams to compensate for missing context by minting ever-broader roles, which is how super_admin ends up assigned to a hundred accounts.

Pure ABAC’s primary risk is policy bugs that fail open. A malformed rule, an unhandled INDETERMINATE state, or a missing attribute can flip a deny into an allow if the engine is not strictly default-deny. ABAC also concentrates trust in the attribute pipeline: if any attribute (especially tenantId, ownerId, or clearance) can be forged, every policy reading it is compromised. This is why attribute provenance and cryptographic verification matter as much as the policy logic — a point the ABAC implementation guide treats in depth.

Whichever you choose, enforce the decision at a single, well-tested boundary rather than re-deriving it in each handler. Centralizing enforcement is the difference between a model you can audit against OWASP ASVS and a scatter of if (user.isAdmin) checks that drift apart over time. The deepest RBAC modeling concern — letting senior roles inherit junior permissions without creating cycles or transitive escalation — is involved enough to warrant its own walkthrough in modeling hierarchical roles and permission inheritance.

The Signals That You Have Outgrown Roles

The Layered Answer Most Systems Land On

Migrating From Roles to Attributes Without a Rewrite

The migration is rarely all-or-nothing. The usual path keeps the role table as the coarse grant and moves the exceptions — the conditions that were multiplying roles — into policy, one capability at a time.

Start with the capability whose roles have multiplied most, because it has the clearest before-and-after. Write the attribute rule that expresses the condition, then run it in shadow mode: evaluate both the role check and the new rule on every request, act on the role check, and log disagreements. A week of production traffic tells you whether the rule matches reality far more reliably than a test suite written from the same assumptions that produced the roles.

When the disagreement log is empty, switch that capability to the new rule and delete the roles that existed only to encode the condition. Repeat. Because each step is scoped to one capability, a mistake affects one feature rather than the whole product, and you can stop at any point with a system that is coherent.

Two things make this go badly. The first is migrating without an audit log of grant changes, which leaves you unable to answer what access looked like before — so build that log first if it does not exist. The second is treating attributes as a place to put everything: rules that read a dozen attributes are as unreviewable as a hundred roles, just in a different file. The test is whether someone outside the team can read the rule and predict the outcome.

Frequently Asked Questions

Related

• Designing Role-Based Access Control Systems — schema, middleware, and revocation patterns for production RBAC.
• Implementing Attribute-Based Access Control — attribute normalization and policy evaluation for ABAC.
• Modeling Hierarchical Roles and Permission Inheritance — role DAGs, transitive closure, and cycle avoidance.
• Policy Enforcement Points in Microservices — where to evaluate decisions across service boundaries.
• Relationship-Based Access Control with OpenFGA — Zanzibar-style authorization when relationships drive access.