Skip to main content
Architecture & Engineering

RBAC (Role-Based Access Control)

Role-based access control grants permissions to roles rather than to individuals, and assigns users to roles. Changing what an entire group can do becomes a single edit to the role, instead of updating every user — which is what makes access reviewable and auditable at scale.

The auditability is the point. Answering "who can delete customer records?" is a question about one role, not an inspection of every user account. That property is what compliance frameworks such as SOC 2 are looking for when they ask about access control.

Roles do have limits. When permissions start depending on context — the owner of a record, the region a user is in, the time of day — role proliferation follows, and teams end up with dozens of near-identical roles. That is the point at which attribute-based access control, which evaluates rules against properties of the user and the resource, becomes the cleaner model.

Codazz builds this in production — Authentication & SSO.

FAQ

RBAC (Role-Based Access Control)
FAQ.

Common questions about rbac (role-based access control).

Ask Us Anything

RBAC grants permissions through named roles — an editor can publish. ABAC evaluates rules against attributes — a user can edit a document if they own it and it is not locked. RBAC is simpler to reason about and audit; ABAC handles context-dependent rules without role explosion. Many systems use RBAC as the base with a few attribute-based rules layered on.