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 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, or the full Clerk and Auth0 feature comparison.
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 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 does. Authentication establishes who someone is; 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) 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, 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 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 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 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 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.
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
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", 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 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 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 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 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 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 (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 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 covers it.
OWASP's Authorization Cheat Sheet 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, §3.1.2.3, p. 20). NIST SP 800-178 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 (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 against what it calls "wrestling with 14 individual permission checkboxes," and capped custom roles at 10. Vercel, Linear and Sentry all ship named workspace roles.
Clerk's model maps to flat, or Core, RBAC. Its organization roles and permissions 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 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 puts at its center: does user U have relation R to object O?
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 (author preprint) 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 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 records that Gates coined "relationship-based access control" in 2007, 12 years before Google published Zanzibar.
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 is built on OpenFGA, which Okta engineers developed and which the CNCF accepted as an 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 covers how each of these models gets built.
Frequently asked questions
Part 2 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
- Role-Based Access Control (RBAC) for B2B SaaS (you are here)
- Role-Based Access Control (RBAC) for B2B SaaS - Part 2