RBAC vs ABAC: Choosing an Access Control Model for a Growing Product

Most products start with a handful of roles, and that works well for a while. Then the product adds customers with their own teams, several sites or brands, new content types and enterprise buyers who ask for permissions that match their organization chart. Each requirement becomes another role, until nobody can say who may do what.

For most growing products, the practical answer to RBAC vs ABAC is a combination: roles for the broad shape of what people do, and attribute-based rules for the conditions roles cannot express, such as which tenant, site, record owner or status a permission applies to.

This article compares RBAC, ABAC and relationship-based access control, shows the same rule written in each model, explains role explosion and sets out how to replace hard-coded roles with policies without breaking the product. It does not cover network access control or identity provider setup.

Key takeaways

• RBAC is simple to understand and audit, but it multiplies roles when permissions depend on context.
• ABAC handles context well through rules over attributes, but policies are harder to read and test without good tooling.
• Relationship-based access control (ReBAC) decides access from relationships, such as membership of a team or ownership of a folder, and suits collaboration products.
• Most products end up with roles plus attribute conditions, enforced on the server in one central place.
• Broken access control ranks first in the OWASP Top 10, so permission changes deserve the most thorough tests in the codebase.
• In a delivered redesign, a multi-site legal marketing CMS replaced hard-coded roles with a policy, resource and action model, with full test coverage on authorization paths.

RBAC, ABAC and ReBAC compared

NIST describes ABAC as a method in which access is granted by evaluating attributes of the subject, the object and the requested operation, and sometimes the environment, against policies. Policy-based access control is often used as another name for ABAC, especially when rules are written as policies of the form principal, action, resource and conditions, as in AWS IAM.

The same rule in three models

Take a rule from a multi-site publishing platform: "Editors can publish articles on the sites they are assigned to. Legal content needs a senior editor."

RBAC. You create a role for each combination: Site A editor, Site A senior editor, Site B editor, Site B senior editor and so on. With 5 sites, 4 role levels and 6 content types that need different rules, the platform can need up to 120 roles. Each new site adds another 24.

ABAC. You write one policy: allow publish on an article when the user's assigned sites include the article's site, and, when the article's category is legal, the user's level is senior. A new site is just a new attribute value, with no new roles.

Hybrid. You keep three or four roles, such as viewer, editor, senior editor and admin, and add attribute conditions for site and category. Roles stay readable for administrators, and the conditions handle the context.

Signs that roles are no longer enough

• Role names include a place or a customer, such as "Berlin manager" or "Acme admin".
• New customers or sites require developer work to add roles.
• Exceptions are handled in code, with checks such as "if user is admin or user ID equals 42".
• Enterprise buyers ask for custom roles or for permissions limited to their own departments, regions or projects.
• Access reviews take days, because nobody can explain what each role really allows.
• Permissions are hard-coded in tokens, so a change in someone's access waits until their session expires.

How to design access control that scales

Enforce on the server, in one place

Every request is checked on the server by a single authorization service or library, never only in the interface. Hiding a button is a usability feature, not a security control. Broken access control ranks first as A01 in the OWASP Top 10, and a common cause is a check that exists in the interface but not on the server.

Model the vocabulary first

Write down the resources, such as articles, sites, invoices and patient records; the actions, such as view, edit, publish, export and delete; and the attributes that matter, such as tenant, site, owner, status, department and sensitivity. Policies are only as clear as this vocabulary.

Keep permissions out of long-lived tokens

Putting a full list of permissions into a JSON Web Token makes every check fast, but a change in someone's access then waits until the token expires. Keep tokens short-lived and limited to identity, or check permissions against a store that can be updated and revoked immediately.

Use a policy engine when rules multiply

For a few rules, code in one authorization module is enough. When rules multiply, a policy engine separates policies from application code, so they can be reviewed, versioned and tested on their own. Open Policy Agent, a graduated Cloud Native Computing Foundation project, and Cedar, an open-source policy language from AWS, are common choices. For sharing and team-based permissions, tools based on Google's Zanzibar design, such as OpenFGA and SpiceDB, store relationships and answer questions like "can this user view this document?" quickly at scale.

Test permissions like payments

Build a permission matrix, listing roles, attribute combinations, resources and actions, and turn it into automated tests that check both allowed and denied cases. Run them on every change to authorization code.

Log decisions on sensitive actions

Record who was allowed or denied what, and why, for exports, deletions, permission changes and access to sensitive records. Our guide to audit logs covers what to record.

Replacing hard-coded roles with policies

1. Inventory current permissions. List every role, every permission check in the code and every exception. Most products find checks scattered across controllers, templates and database queries.
2. Define the target model. Choose the roles you keep, the attributes you add and the policies that replace exceptions.
3. Centralize checks first. Route every permission check through one function or service, still using the old logic. This step alone removes most inconsistencies.
4. Run old and new side by side. Evaluate the new policies in shadow mode on real traffic, log every case where the old and new answers differ, and fix the policies until the differences are explained.
5. Switch over in stages. Move one resource type or one tenant at a time, with the ability to switch back.
6. Give administrators a clear interface. A policy model only helps if customers and support staff can see and manage permissions without developer help.

Access control redesigns in delivered projects

A multi-site CMS that outgrew its roles

A US law firm runs multiple marketing websites on Verba, a custom content management system. Hard-coded roles blocked growth across sites, and permissions could not scale to the growing number of content types. A .wrk team replaced the roles with a policy model of resources and actions, similar to AWS IAM policies, with revocable tokens instead of permissions baked into JSON Web Tokens. The redesign shipped with 100% test coverage on authorization paths. The platform now has granular access control across sites, and new firm sites launch faster from shared components. Read the Verba CMS case study.

Subscription tiers on a publishing site

Connell Guides, a UK publisher of study guides, sells a digital subscription with e-books, discussions and video. As part of a Drupal modernization, .wrk set up roles and permissions for each subscription tier, so content access follows what each customer has paid for. Read the Connell Guides case study.

Role-based approvals in healthcare

For a Canadian healthcare platform working toward SOC 2 Type 2, .wrk introduced role-based approvals and code review gates for changes, and isolated the legacy system to admin-only functions that auditors could examine separately. Read the healthcare platform case study.

Access control for AI features

AI assistants and agents need the same model as people. An assistant that searches documents should only retrieve what the user asking the question may see, and an agent that acts in business systems should have its own identity with the narrowest permissions it needs. Our guides to AI agent security and context engineering cover permission-aware retrieval and agent identities.