RBAC (role-based access control) decides what a user can do from the role they hold. ABAC (attribute-based access control) decides from attributes of the user, the resource, the action and the context, evaluated at request time. For most SaaS products the answer is not either/or: start with RBAC, and add attribute conditions only where a role cannot express the rule.
I'm Hanad, a senior software engineer in Vienna. I build first versions of SaaS products and rebuild prototypes into maintainable code, so permissions come up in nearly every project. This article explains the two models, where each one breaks, and how I would pick for a product with real customers.
Key Takeaways
- RBAC answers "what kind of user is this?" ABAC answers "given everything about this request, should it be allowed?"
- RBAC is easier to build, explain and audit. Its typical failure is role explosion, with a new role for every exception.
- ABAC is more expressive. Its typical failure is attribute sprawl, with stale tags and rules nobody can fully review.
- Most mature SaaS products layer the two: roles for the coarse structure, attribute conditions for tenant, ownership, region or time.
- For an MVP, ship RBAC with tenant scoping first, and design it so attribute rules can be added later.
Table of Contents
- The difference in one table
- What RBAC is
- What ABAC is
- Which one fits your product
- Combining them without making a mess
- RBAC vs PBAC and RBAC vs IAM
- Mistakes I would avoid
- Perspective
- Need this built properly?
- FAQ
- Sources
The difference in one table
| RBAC | ABAC | |
|---|---|---|
| Decision based on | The role assigned to the user | Attributes of user, resource, action and environment |
| When it is decided | Role assigned ahead of time | Evaluated per request |
| Typical rule | "Managers can approve invoices" | "Managers can approve invoices in their own region, under their limit, during business hours" |
| Setup effort | Upfront role design | Attribute modeling and policy writing |
| Answering "who can do what?" | Easy: look up the role | Harder: run the rules |
| Typical failure | Role explosion | Attribute sprawl |
| Best fit | Stable job functions, early products | Contextual, data-level or regulated access |
What RBAC is
NIST's glossary defines RBAC as a model where permitted actions are tied to roles rather than to individual identities. You define roles such as owner, admin, editor and viewer, attach permissions to each role, and assign users to roles. When someone changes jobs, you change their role, not fifty individual permissions.
A university access standard lists the principles that make this work: roles are defined, permissions attach to roles and not to people, and least privilege and separation of duties guide the design. That is exactly why RBAC maps so well to org charts and to the questions an auditor asks.
In a SaaS product, RBAC usually looks like a role column on a membership record (user, organization, role) and a check in the API: "does this role include invoice:approve?" I have written up the practical build in role-based access control for SaaS.
Where RBAC is strong
NIST researchers describe the trade-off this way: RBAC takes effort up front to structure roles, and in return makes administration and permission review easy. Once the roles exist, you can answer "what can this person do?" by reading one record. That matters when a customer's security team sends a questionnaire or when you prepare for due diligence.
Teams that need to explain permissions to non-engineers benefit too. A product whose roles are named in the customer's own vocabulary is easy to document. A quantity-surveying software team, for example, has written about who should see and change what in role permissions, which shows how naturally roles map to real job functions.
Where RBAC breaks
The OWASP handbook names the common failure mode of RBAC as role explosion: a role per exception. It starts innocently. "Editor" becomes "Editor who can't delete," then "Editor for the EU team only," then "Editor for the EU team who can export." A year later you have forty roles and nobody knows what "Editor 3" means.
The NIST paper puts a worst case on it: reproducing attribute-style controls in RBAC could in theory require one role for every combination of attributes. In practice you will never hit the worst case, but the direction is clear: the more your rules depend on context, the more roles you need.
What ABAC is
NIST SP 800-162 defines ABAC as a method where requests to perform operations on objects are granted or denied based on attributes of the subject, attributes of the object, environment conditions, and a set of policies written in terms of those attributes.
The attribute categories are intuitive. NIST's cybersecurity center gives the pattern: with RBAC users arrive at a resource holding privileges through an assigned role, while with ABAC privileges are determined just in time. That just-in-time evaluation is what lets a policy use things like device, location or the current state of the resource.
A concrete example for a B2B product:
- User attributes: department, region, seniority, whether they completed security training.
- Resource attributes: which tenant owns it, sensitivity level, status (draft, submitted, locked).
- Action: read, edit, export, approve.
- Environment: time of day, network, device posture.
A rule might say: allow export when the user's tenant equals the resource's tenant, the resource is not marked restricted, and the user's department is finance. No role named "Finance Exporter" is needed.
Where ABAC is strong
NIST notes that ABAC's flexibility can let a broad range of subjects access a broad range of objects without specifying individual relationships between each subject and object. When a new resource appears with the right attributes, existing policies cover it automatically. The same document observes that doing the same with ACLs or RBAC is possible, but demonstrating compliance becomes difficult and costly, and changing a requirement means hunting for every place the implementation must be updated.
That makes ABAC a good fit when access is genuinely about data: multi-tenant isolation, patient or client records, regional data residency, or approval limits that depend on amounts.
Where ABAC breaks
NIST is direct about the cost: development, deployment and maintenance of ABAC may exceed its benefits in the long term, and it is not the right solution for every access control problem. The OWASP handbook names the typical failure as attribute sprawl, where tags drift out of date.
The review problem is the one I see most. The NIST researchers note that with ABAC determining the permissions available to one user may require running a large set of rules in exactly the order the system applies them. If your customer asks "what can this account manager touch?", the honest answer becomes "it depends," and that is hard to put in an audit report. IT teams that manage conditional access policies face the same issue, which is why a practical guide to conditional access policies stresses reviewing what a policy actually grants to whom.
Which one fits your product
Use these questions, in order.
- Do your rules depend only on job function? If "admins can invite, editors can edit, viewers can read" covers 90% of your cases, use RBAC.
- Do you need tenant isolation? This is not really a role question. Every query must be scoped to the customer's organization. Treat it as an attribute rule (tenant ID on user equals tenant ID on resource), ideally enforced in the database as in Postgres row-level security for multi-tenant apps.
- Do exceptions keep multiplying roles? If you are inventing roles to express "only their own region" or "only drafts," add an attribute condition instead.
- Will you be audited? Keep a role layer so you can produce a clear permission matrix, and log changes (audit logging for SaaS covers what to record).
- Do you have the capacity to maintain policies? ABAC needs someone who owns attribute definitions and reviews rules. A two-person team often does not.
A worked example
Imagine a B2B invoicing product with three customer types and about 200 organizations. Roles: owner, finance, staff, auditor. That is four roles and a short permission matrix.
Now the customer requests arrive:
- "Finance in our Berlin entity must not see Vienna invoices." That is a region attribute on the user and the invoice.
- "Staff can edit invoices only while they are drafts." That is a status attribute on the resource.
- "Approvals above a limit need an owner." That is an amount attribute compared with the role.
In pure RBAC you would add roles like "Finance Berlin," "Finance Vienna," "Staff Draft Editor" and multiply them per entity. With a hybrid, the four roles stay, and three small conditions sit beside them. The role answers "may this person approve invoices at all?" and the conditions answer "this one, now?"
A codelit.io analysis gives a rough illustration of the arithmetic: a SaaS product with 50 features and 4 access levels could need 200 roles under RBAC. Treat the figure as an illustration of scale, not a benchmark, but the multiplication effect is real.
Combining them without making a mess
The OWASP handbook describes the pattern mature teams settle on: RBAC supplies the coarse role and ABAC conditions narrow that role's grant to the specific resources and context it should apply to. NIST's cybersecurity center also notes that some authors have implemented and documented hybrid ABAC-RBAC solutions, and it recommends analyzing alternative solution classes against your actual constraints before committing.
Here is the structure I use in practice:
- Authenticate the user and load their membership (organization and role). See login and auth for an MVP for what to build first.
- Check the role for the action. This is a lookup in a permission table.
- Check conditions on the resource: same tenant, allowed status, ownership, region.
- Log the decision for sensitive actions.
- Keep it in one place. One authorization function, called by every endpoint, instead of checks scattered through the UI and handlers.
Step 5 matters most. The failure I see in prototypes is not choosing the wrong model. It is that permissions live in front-end conditions and a dozen copy-pasted API checks, so no model is really enforced.
RBAC vs PBAC and RBAC vs IAM
Two neighboring questions come up often.
PBAC (policy-based access control). NIST's glossary defines it as a form of access control using an authorization policy that is flexible in the types of evaluated parameters, such as identity, role, clearance, operational need or risk. Think of it as the way you write and manage rules: policies stored as reviewable files, evaluated by a central decision point. RBAC is a model of who gets what; PBAC is a style of expressing and governing rules that can include roles and attributes together.
IAM (identity and access management). IAM is the whole discipline: identities, authentication, lifecycle, and authorization. RBAC is one authorization method that can live inside it. Login, MFA and session handling are IAM concerns; "can editors export?" is an RBAC concern. For the authentication side, see MFA for SaaS.
Mistakes I would avoid
- Roles named after people. "Sarah's role" is a sign the model is being bent around exceptions.
- Attributes nobody owns. If "department" comes from a spreadsheet someone updates quarterly, your policy is only as accurate as that spreadsheet.
- Skipping the permission matrix. Write down roles against actions on one page before you code. If it does not fit, the design is too complex.
- No deny-by-default. Anything not explicitly allowed should be refused.
- No tests. Permission rules are code. Test that a user from tenant A cannot read tenant B, and run it on every release.
- Security as an afterthought. Access control is one item on a broader list; the SaaS security checklist shows where it sits.
Perspective
I rebuild a lot of prototypes that were generated or assembled quickly. Almost all of them have the same permission story: a role flag on the user, checks hidden in the front end, and no real tenant isolation. Founders ask me whether they need "enterprise ABAC." Usually they do not.
What they need is a small, honest RBAC model, a hard tenant boundary, and an authorization layer written so attribute rules can be added when a real customer asks for one. That is a two-to-four-week piece of work inside a first real version, not a separate project.
I choose deliberately boring tools for this: TypeScript, SQL, and a single authorization module the next developer can read in an afternoon. Fancy policy engines have their place, but a product with a handful of roles and three conditions should not carry that weight. If a managed off-the-shelf option fits your case, I will tell you so.
Hanad Kubat
Need this built properly?
If your prototype has a role flag and not much else, or you need a first version with real logins, roles and tenant isolation, I build it as a fixed-price engagement. Your app starts from €12,000. The price is possible because there is no agency overhead, no project-manager layer and no offshore markup, you talk to the engineer who writes the code, and you own it from the first commit.
FAQ
When should I use ABAC instead of RBAC?
Use ABAC when access depends on conditions a role cannot express: the data's owner or region, a record's status, an amount, or the context of the request. If you are inventing roles to cover exceptions, that is the signal. Keep roles for the broad structure and add attribute conditions on top.
Can RBAC and ABAC be used together?
Yes, and most mature products do. Roles decide what kind of actions a user may attempt, and attribute conditions decide whether this specific request on this specific resource is allowed. OWASP describes this layering as how experienced teams combine the two.
Is ABAC more secure than RBAC?
Neither is secure by itself. Security depends on correct enforcement, deny-by-default rules, testing and review. ABAC can express finer rules, but a large rule set is harder to review. RBAC is simpler to audit but can grant too much if roles are broad.
What is the difference between RBAC and PBAC?
RBAC grants permissions through roles. PBAC evaluates policies that can combine identity, role, risk and other parameters, as NIST's definition describes. In practice PBAC is about how rules are written, stored and evaluated, and it can include both roles and attributes.
Which should an MVP start with?
Start with RBAC and strict tenant scoping. It is quick to build, easy to explain to customers, and enough for most early products. Put all permission checks in one module so adding attribute rules later does not mean rewriting the app.
Sources
- NIST SP 800-162: Guide to Attribute Based Access Control (ABAC)
- NIST SP 800-162 (legacy edition)
- Adding Attributes to Role-Based Access Control (NIST, 2010)
- NCCoE: Attribute Based Access Control
- NIST CSRC glossary: role-based access control
- NIST CSRC glossary: policy based access control
- OWASP: Identity and Access Management
- UNCSA Access Control Standard
- Codelit: RBAC vs ABAC guide
- QuantiFlow: role permissions
- Conditional access policies guide