RBAC vs ABAC: Designing Authorisation for Your App

A
Author
21 May, 2026 1 min read 767 views

Authentication answers "who are you?". Authorisation answers "may you do this?". As apps grow, a clear authorisation model saves you from permission checks scattered everywhere.

RBAC: role-based access control

const PERMISSIONS = {
  admin:  ['post:create', 'post:edit', 'post:delete', 'user:manage'],
  editor: ['post:create', 'post:edit'],
  author: ['post:create'],
};

const hasPermission = (user, permission) => PERMISSIONS[user.role]?.includes(permission) ?? false;
  • Simple to understand, audit and explain to customers.
  • Struggles with resource-specific rules like "authors can edit their own posts".
  • Leads to "role explosion" if you create a role for every combination.

ABAC: attribute-based access control

Decisions use attributes of the user, the resource and the context:

const policies = {
  'post:edit': ({ user, post }) =>
    user.role === 'admin' ||
    user.role === 'editor' ||
    (user.role === 'author' && post.authorId === user.id && post.status === 'draft'),

  'invoice:view': ({ user, invoice }) =>
    invoice.tenantId === user.tenantId && (user.role === 'admin' || user.department === 'finance'),
};

export function authorize(action, ctx) {
  const rule = policies[action];
  if (!rule || !rule(ctx)) throw new HttpError(403, 'Forbidden');   // deny by default
}

// In a handler
authorize('post:edit', { user: req.user, post });
  • Expresses ownership, tenancy, status and time-based rules naturally.
  • More flexible, but harder to audit ("who can do X?") without good tooling.

Practical design

  • Most apps use RBAC plus a few attribute rules (ownership and tenant checks).
  • Put all rules in one module; handlers call authorize(), never inline if (user.role === ...).
  • Enforce on the server. Hiding buttons in the UI is a convenience, not security.
  • Filter list queries too: "list invoices" must return only what the user may see.
  • Write tests for each rule, including the denials.

For complex products, policy engines and authorisation services (Open Policy Agent, Cedar, Zanzibar-style systems like OpenFGA) let you manage rules outside application code.

Was this article helpful?

Comments

No comments yet. Have a question or a tip? Be the first to share it.

Leave a comment

Comments are reviewed before they appear.