RBAC

How it works

RBAC (Role-Based Access Control) grants permissions to roles, then assigns roles to users, so access is decided by the role a user holds rather than by per-user rules. An admin defines roles like "viewer," "editor," and "billing-admin," attaches a set of permissions to each, and a user inherits every permission of their assigned roles. Checking access becomes "does this user have a role that permits this action?" It is the most widely deployed authorization model because it is simple to reason about and easy to audit.

When it matters

RBAC matters for most applications up to a moderate level of complexity: a handful of roles cleanly express who can do what, and adding a user to a role is a one-step operation. It is the right default until your authorization needs become contextual (per-resource, per-attribute, or relationship-driven), at which point teams reach for ABAC or ReBAC. Map SSO group claims to roles when you add enterprise login. See Add SSO to Your B2B SaaS.

Common misconceptions

• "RBAC scales to any complexity." It suffers "role explosion" when you need many fine-grained combinations; that is the signal to consider ABAC or ReBAC.
• "Roles and groups are the same." Groups collect users; roles collect permissions. They often map to each other but are distinct concepts.
• "RBAC handles per-record sharing." It does not, natively. Sharing "this specific document with this user" is a relationship problem better suited to ReBAC.