# Role-Based Access Control (RBAC) for B2B SaaS

**What is role-based access control (RBAC), and which access control model should a B2B SaaS team choose?**

Role-based access control assigns permissions to named roles, then grants users access by assigning them roles, so a user never holds a permission directly. In B2B SaaS, roles are scoped to a tenant rather than globally: the same person can be an Admin in one workspace and a read-only Member in another. RBAC itself comes in four standardized variants: flat, hierarchical, constrained and symmetric. It competes with ABAC, ACLs and ReBAC. This guide compares all of them and says which to pick.

This part covers the model and its mechanics, where those four variants come from in the NIST and ANSI standards, and how RBAC compares against ABAC, ACLs and ReBAC. [Part 2](https://clerk.com/articles/role-based-access-control-rbac-for-b2b-saas-2.md) covers multi-tenant scoping, role explosion, roles in session tokens, auditability, the three implementation approaches, and Clerk's organizations model. Neither part covers pricing, [per-framework implementation code](https://clerk.com/articles/organizations-and-role-based-access-control-in-nextjs.md), or the full [Clerk and Auth0 feature comparison](https://clerk.com/articles/clerk-vs-auth0-which-authentication-platform-fits-your-team-2.md).

> Vendor capabilities described here were verified against each vendor's own documentation as of the publish date. Access control features move quickly, so confirm against current docs before committing to a design.

## What is role-based access control (RBAC)?

Role-based access control is "a model for controlling access to resources where permitted actions on resources are identified with roles rather than with individual subject identities," in the definition the [NIST Computer Security Resource Center](https://csrc.nist.gov/glossary/term/role_based_access_control) attributes to SP 800-95. Permissions attach to the role. Users get access by being assigned that role.

RBAC answers a different question than [authentication](https://clerk.com/glossary.md#authentication) does. Authentication establishes who someone is; [authorization](https://clerk.com/glossary.md#authorization) decides what they may do once identity is settled, and RBAC is one way of deciding it. The IETF's [Internet Security Glossary, Version 2 (RFC 4949)](https://www.rfc-editor.org/rfc/rfc4949.txt) defines authentication, authorization, access control and RBAC in a single document if you want the vendor-neutral versions side by side.

[Ferraiolo and Kuhn formalized the model at NIST in 1992](https://csrc.nist.gov/projects/role-based-access-control), and ANSI standardized it in 2004.

NIST also names the cost of the model, which vendor pages skip. The Discussion under control AC-3(7) in [NIST SP 800-53 Rev. 5](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf) notes that role-based access control "can also increase privacy and security risk if individuals assigned to a role are given access to information beyond what they need to support organizational missions or business functions."

### How RBAC works: users, roles, and permissions

RBAC is built from four elements and two assignment relations, using the vocabulary of the [proposed NIST standard](https://csrc.nist.gov/csrc/media/projects/role-based-access-control/documents/rbac-std-draft.pdf) that became the ANSI standard:

- **Users** are the people (or services) requesting access. A user is never described by what they can do, only by which roles they hold.
- **[Roles](https://clerk.com/glossary.md#roles)** are named job functions inside your product: Owner, Admin, Billing Manager. The standard's own definition is "a job function within the context of an organization."
- **[Permissions](https://clerk.com/glossary.md#custom-permissions)** are approvals to perform an operation on an object: delete a project, invite a member, read an invoice. Roles bundle them.
- **Sessions** map one user to the roles they've activated for a given interaction, so a user can hold several roles without exercising all of them at once.

Two relations connect them: user-role assignment puts people into roles, permission-role assignment puts capabilities into roles. Both are many-to-many.

One invariant holds the model together: **permissions are never granted directly to a user.** That indirection lets you answer "what can this role do?" once instead of per person, and revoke a capability from 400 people with a single edit.

### A role-based access control example: roles and permissions in a SaaS workspace

Take a B2B workspace product with four roles. Each role bundles permissions, and a user gets the bundle by assignment.

| Role            | Bundled permissions                                                    | Typical assignee              |
| --------------- | ---------------------------------------------------------------------- | ----------------------------- |
| Owner           | Everything Admin has, plus transfer ownership and delete the workspace | Whoever created the workspace |
| Admin           | Invite and remove members, change roles, edit any project              | Team leads                    |
| Member          | Create and edit their own projects, read shared projects               | Most of the customer's staff  |
| Billing Manager | View and change the subscription, download invoices                    | Finance, often nobody else    |

Billing Manager holds capabilities Admin doesn't, and vice versa. Roles are job functions rather than seniority tiers, which keeps the set small. These four roles are the running example for the rest of this guide.

## RBAC models: flat, hierarchical, constrained, and symmetric

| Model        | What it adds                                          | When you need it                           | Cost                                          |
| ------------ | ----------------------------------------------------- | ------------------------------------------ | --------------------------------------------- |
| Flat (Core)  | Roles carry permissions, plus user-role review        | Almost every B2B SaaS product, on day one  | Duplication as role count grows               |
| Hierarchical | Inheritance: senior roles acquire junior permissions  | Many roles differing by a few permissions  | "Why does this user have access?" gets harder |
| Constrained  | Separation of duty across conflicting roles           | Regulated and finance-adjacent products    | Conflict rules to maintain and test           |
| Symmetric    | Permission-role review: which roles hold a permission | Access reviews and security questionnaires | Query work on the permission side             |

Sandhu, Ferraiolo and Kuhn's 2000 paper, which named the levels, is explicit that "these levels are cumulative and each adds exactly one new requirement," so symmetric RBAC includes everything below it. That framing belongs to the paper, not to the standard that followed.

### The NIST RBAC model and ANSI INCITS 359

Flat, hierarchical, constrained and symmetric RBAC come from [Sandhu, Ferraiolo and Kuhn, "The NIST Model for Role-Based Access Control: Towards a Unified Standard"](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf), presented at the 5th ACM Workshop on RBAC in 2000.

NIST then revised that proposal, before ANSI balloting rather than during it, and the levels became components: flat became Core RBAC, symmetric's permission-role review became an optional advanced review function on Core, and constrained split into Static and Dynamic Separation of Duty components a system can adopt independently. ANSI ratified the revised model as INCITS 359-2004. [NIST's own FAQ](https://csrc.nist.gov/projects/role-based-access-control/faqs) describes the ratified standard as four components, not four levels, and the terms "flat" and "symmetric" appear nowhere in it.

Pages citing "the NIST model" merge the 2000 four-level proposal with the 2004 four-component standard that reorganized it four years later.

### Flat RBAC (Core RBAC)

Flat RBAC is the base: users are assigned to roles, roles are assigned permissions, and both assignments are many-to-many. There's no inheritance. A role holds exactly the permissions you gave it.

The level also requires user-role review, meaning the system can enumerate which users hold a given role and which roles a given user holds. Without that requirement you have a `role` column no query can enumerate.

Flat RBAC is the model most B2B SaaS products ship, and it covers what the large majority of them need. A workspace of Owner, Admin, Member and Billing Manager is flat: each role carries its own permission set, with no structural relationship between them.

### Hierarchical RBAC: role inheritance and role hierarchies

Hierarchical RBAC adds inheritance: "a partial order defining a seniority relation between roles, whereby senior roles acquire the permissions of their juniors, and junior roles acquire the user membership of their seniors," in the standard's wording. Grant a permission to Member and every role above it picks it up in one edit.

Inheritance carries a cost. When a permission arrives through inheritance, answering "why does this user have access to this?" takes a graph traversal rather than a lookup, and auditors ask that question more often than your engineers do.

The [proposed NIST standard](https://csrc.nist.gov/csrc/media/projects/role-based-access-control/documents/rbac-std-draft.pdf) separates general hierarchies, an arbitrary partial order supporting multiple inheritance, from limited hierarchies, where "a role may have one or more immediate ascendants, but is restricted to a single immediate descendent." [OASIS's XACML 3.0 RBAC Profile](https://docs.oasis-open.org/xacml/3.0/rbac/v1.0/xacml-3.0-rbac-v1.0.html) implements the same relation against the ANSI component names, corroboration that the definition isn't NIST-specific.

### Constrained RBAC and separation of duties

Constrained RBAC adds separation of duty: rules stopping one user from holding roles that together let them act unchecked. The classic case is expenses, where whoever submits a claim can't approve it.

Static separation of duty blocks the assignment itself, so a user never holds both roles. Dynamic separation of duty allows both assignments but blocks activating both in one session.

This matters in regulated and finance-adjacent products. The [AICPA's Trust Services Criteria](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) carry a point of focus under CC6.3 for using "access control structures, such as role-based access controls," to "limit privileges, and support segregation of incompatible functions." The wording is narrower than it looks. RBAC appears there only as an example, CC6.3's own criterion says "roles, responsibilities, or the system design," and TSC paragraph .07 says points of focus need not be individually assessed.

Most B2B SaaS teams skip this level, and OASIS put SSD and DSD explicitly out of scope in its XACML RBAC profile. [Part 2](https://clerk.com/articles/role-based-access-control-rbac-for-b2b-saas-2.md) covers audit and access reviews.

### Symmetric RBAC and permission review

Symmetric RBAC adds permission-role review: you can ask which roles hold a given permission, about as fast as you can ask the reverse.

In the [proposed NIST standard published in ACM TISSEC](https://csrc.nist.gov/pubs/journal/2001/08/proposed-nist-standard-for-rolebased-access-contro/final) (Ferraiolo et al., 4(3), 2001, §4.1.3, p. 243), only two of Core RBAC's eight review functions are mandatory: `AssignedUsers` and `AssignedRoles`. `UserPermissions` is optional. A standards-conformant RBAC system answers "which roles does Alice have?" but need not answer "what can Alice do?", the question your auditor asks. [Part 2](https://clerk.com/articles/role-based-access-control-rbac-for-b2b-saas-2.md) covers what that gap costs at audit time.

### Which RBAC model does B2B SaaS actually need?

Start flat, and add hierarchy when role count and duplication make it pay for itself. Treat constrained RBAC as compliance-driven rather than a default. Tenant scoping is what makes that verdict hold in multi-tenant products, and [Part 2](https://clerk.com/articles/role-based-access-control-rbac-for-b2b-saas-2.md) covers it.

[OWASP's Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) argues the other way, saying "ABAC and ReBAC should typically be preferred for application development." NIST's own guide to ABAC concedes the cost of a "before the fact audit," the compliance review of what access each person holds: "An ABAC system may not lend itself well to conducting these audits efficiently" ([SP 800-162](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-162.pdf), §3.1.2.3, p. 20). [NIST SP 800-178](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-178.pdf) generalizes the point: reviewing logical-formula policy is equivalent to the satisfiability problem and "may become exponentially more difficult to analyze as the size of the policy increases" (p. 47), while reviewing enumerated policy is "relatively simple." Expressiveness and reviewability trade against each other, and B2B SaaS gets audited.

[Kuhn, Coyne and Weil](https://csrc.nist.gov/files/pubs/journal/2010/06/adding-attributes-to-rolebased-access-control/final/docs/kuhn-coyne-weil-10.pdf) (IEEE Computer 43(6), 2010) put numbers on the RBAC-plus-attributes hybrid: an example needing 1,024 roles under pure RBAC or 1,024 rules under pure ABAC drops to 16 roles plus 64 rules when its 10 attributes are split 4 static and 6 dynamic.

Shipped B2B products keep choosing roles. [Atlassian made RBAC generally available in Confluence Cloud in 2026](https://community.atlassian.com/forums/Confluence-Cloud-Admins-articles/Coming-soon-Role-based-access-control-in-Confluence-GA/ba-p/3248592) against what it calls "wrestling with 14 individual permission checkboxes," and [capped custom roles at 10](https://support.atlassian.com/confluence-cloud/docs/create-and-manage-custom-roles/). [Vercel](https://vercel.com/docs/rbac/access-roles), [Linear](https://linear.app/docs/members-roles) and [Sentry](https://docs.sentry.io/organization/membership/) all ship named workspace roles.

Clerk's model maps to flat, or Core, RBAC. Its [organization roles and permissions](https://clerk.com/docs/guides/organizations/control-access/roles-and-permissions.md) documentation describes no inheritance mechanism; the default admin and member roles happen to nest in practice, but that's default configuration rather than a structural inheritance relation.

## RBAC vs ABAC vs ReBAC

RBAC, ABAC and ReBAC differ in what the access decision reads.

RBAC decides from roles assigned to the user. ABAC decides from attributes evaluated at request time, which [NIST SP 800-162](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-162.pdf) enumerates as attributes of the subject, the object, the requested operation and the environment. ReBAC decides from the graph, asking the question Google's [Zanzibar paper](https://www.usenix.org/system/files/atc19-pang.pdf) puts at its center: does user U have relation R to object O?

| Model | Decision input                                    | Best fit                                            | Main failure mode                                |
| ----- | ------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------ |
| RBAC  | Roles assigned to the user                        | Job-function permissions in a workspace             | Role explosion as customers ask for variations   |
| ABAC  | Attributes of user, resource, action, environment | Context-dependent rules (time, location, clearance) | Effective permissions are hard to enumerate      |
| ReBAC | Relationships between subject and resource        | Nested ownership, sharing, deep hierarchies         | Graph and consistency infrastructure to run      |
| ACL   | Per-resource list of who may do what              | Small systems, per-object sharing                   | "What can this user reach?" walks every resource |

### RBAC vs ABAC

RBAC decides from who the user is, meaning the roles they hold. ABAC decides from attributes of the user, the resource, the action and the environment, evaluated at request time.

Roles and attributes trade against each other in both directions. RBAC is reviewable and cacheable: the set of permissions behind a role is a list you can print. It can't express context, so "contractors can't export data outside business hours" has no natural home in a pure role model.

ABAC expresses exactly that kind of rule. The cost lands on review. The peer-reviewed [2017 ABAC survey in ACM Computing Surveys](https://dl.acm.org/doi/10.1145/3007204) ([author preprint](https://www.csd.uwo.ca/~dservos5/papers/Current%20Research%20and%20Open%20Problems%20in%20Attribute-Based%20Access%20Control%20-%20Preprint.pdf)) names auditability, delegation and administration as open problems in ABAC, and finds that working out who can reach a given resource is "considerably more complicated" in ABAC than in RBAC.

Most products land in the middle: RBAC as the backbone, with a few attribute checks layered on where context matters. NIST SP 800-162 frames the split as a matter of degree rather than a binary, noting that "RBAC works on the attribute of 'role'."

### RBAC vs ACL

An [access control list](https://clerk.com/glossary.md#access-control-list-acl) attaches permissions to each resource, naming which users may do what to it. RBAC attaches permissions to roles, and users to roles.

The practical consequence shows up at review time. Answering "what can this user reach?" under ACLs means walking every resource; under RBAC it's a query against the roles the user holds. Answering the reverse, "who can reach this document?", is the ACL's strength: read that one resource's list.

### RBAC vs ReBAC: relationship-based access control

ReBAC derives decisions from the graph between subject and resource. Is this user a member of the team that owns the folder this document sits in? The model predates its best-known implementation: [Fong's CODASPY 2011 paper](https://pages.cpsc.ucalgary.ca/~pwlfong/Pub/codaspy2011.pdf) records that Gates coined "relationship-based access control" in 2007, 12 years before Google published [Zanzibar](https://www.usenix.org/system/files/atc19-pang.pdf).

ReBAC fits permissions that are graph-shaped, deeply nested, or driven by sharing rather than job function. Document hierarchies, folder trees, and retrieval permissions for AI systems are the cases where roles alone run out.

Auth0 ships a ReBAC engine that Clerk does not. [Auth0 FGA](https://auth0.com/fine-grained-authorization) is built on [OpenFGA](https://openfga.dev/), which Okta engineers developed and which the [CNCF accepted as an incubating project](https://www.cncf.io/blog/2025/11/11/openfga-becomes-a-cncf-incubating-project/) in November 2025. If your authorization problem is relationship-shaped, that's a reason to look at Auth0.

### Which access control model should you choose?

Default to RBAC. It covers job-function permissions in a workspace, and it's the model your auditors already understand.

Reach for attributes when a decision depends on request context that a role can't carry. Reach for ReBAC when it depends on nested ownership or sharing graphs instead. [Part 2](https://clerk.com/articles/role-based-access-control-rbac-for-b2b-saas-2.md) covers how each of these models gets built.

## Frequently asked questions

## FAQ

### What are the four types of access control?

Discretionary (DAC), mandatory (MAC), role-based (RBAC) and attribute-based (ABAC) access control. The count varies by source: [NIST IR 7316](https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7316.pdf) notes that "recent computer security texts often list RBAC as one of the three primary access control policies," and other lists add relationship-based access control (ReBAC) or access control lists (ACLs).

### Can a user have more than one role?

Yes. Core RBAC requires user-role assignment to be many-to-many, so one user can hold many roles. It also requires that users "can simultaneously exercise permissions of multiple roles," which the [proposed NIST standard](https://csrc.nist.gov/csrc/media/projects/role-based-access-control/documents/rbac-std-draft.pdf) says "precludes products that restrict users to activation of one role at a time."

### What is the difference between role-based and rule-based access control?

Role-based access control decides from roles assigned before the request. Rule-based access control decides from conditions evaluated at request time, such as IP range or time of day, and is now usually called attribute-based access control (ABAC).

[Part 2](https://clerk.com/articles/role-based-access-control-rbac-for-b2b-saas-2.md) applies this model to multi-tenant B2B SaaS: scoping roles per tenant, role explosion, roles riding in session tokens, auditability, the three implementation approaches, and how Clerk's organizations model maps onto them.

## In this series

1. **Role-Based Access Control (RBAC) for B2B SaaS** (you are here)
2. [Role-Based Access Control (RBAC) for B2B SaaS - Part 2](https://clerk.com/articles/role-based-access-control-rbac-for-b2b-saas-2.md)