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

Source: https://www.plutonapps.com/resources/what-is-role-based-access-control

Published 2026-09-30, updated 2026-10-24, sources checked 2026-10-24. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib).

**Role-based access control (RBAC):** Role-based access control (RBAC) is a way of managing permissions in which rights are granted to roles, such as owner, admin, editor or viewer, and people are given roles. Changing what a role may do changes it for everyone in that role, without editing each person one by one.

Also known as: RBAC, Role-based security, User roles and permissions.

How an app decides that an editor can publish but a viewer cannot, without a rule for every person.

## Why does RBAC become urgent with the first business customer?

Prototypes often have two kinds of user: the founder, who can do everything, and everyone else. The first business customer asks for more: an admin who manages the team, members who work, a viewer from finance. If roles are bolted on as checks scattered through the interface, some screen or endpoint will always be missed.

## How does RBAC put least privilege into practice?

NIST defines least privilege as restricting access to the minimum needed to do the task. RBAC is how you apply it at scale: start each role with nothing and grant what it needs. Enforce the role on the server or in the database, never only by hiding buttons, and record changes to roles in an [audit log](https://www.plutonapps.com/resources/what-is-an-audit-log).

## What does a simple RBAC model look like in practice?

A simple RBAC model has three parts: a list of permissions, a list of roles, and a table saying which person holds which role. Each role is a named bundle of permissions. Code never asks who a person is; it asks whether their role holds the permission the action needs.

| Permission | Owner | Admin | Editor | Viewer |
| --- | --- | --- | --- | --- |
| View projects | Yes | Yes | Yes | Yes |
| Edit projects | Yes | Yes | Yes | No |
| Invite and remove people | Yes | Yes | No | No |
| Change billing | Yes | No | No | No |

When finance asks for read access, you give that person the viewer role. No new rule is written for them, and if viewers later need to export reports, one change covers everyone with the role.

## How do you add roles to a Supabase or Lovable app?

Supabase documents a pattern for RBAC: store roles in a user_roles table and each role's permissions in a role_permissions table. A custom access token hook adds the user's role to their session token, and an authorize function checks it inside [row-level security](https://www.plutonapps.com/resources/what-is-row-level-security) policies, so the database itself refuses actions a role does not hold.

1. **Model the roles** Create the roles and permissions tables, scoped per organization if people belong to more than one.
2. **Put the role in the token** Enable a custom access token hook under Authentication, Hooks, so each session carries a role claim.
3. **Check it in policies** Write RLS policies that call a function such as authorize('projects.delete').
4. **Mirror it in the interface** Hide buttons a role cannot use, as a convenience only. The database stays the real check.

## What are the most common RBAC mistakes?

Three mistakes cause most RBAC failures: checking roles in the interface but not on the server, giving people one global role when they belong to several organizations, and letting an admin role quietly accumulate every permission ever added, which OWASP calls privilege creep and advises reviewing for after launch.

- Roles checked in the interface but not on the server. OWASP is plain that apps must never rely on client-side access checks.
- One global role when people belong to several organizations.
- An admin role that quietly accumulates every permission ever added. OWASP calls this privilege creep and advises reviewing for it after launch.

If roles in your AI-built app live only in the interface, that is the kind of gap our [vibe-coding rescue](https://www.plutonapps.com/services/vibe-coding-rescue) work starts with.

## Frequently asked questions

### What is the difference between RBAC and ABAC?

RBAC grants rights by role. Attribute-based access control (ABAC) decides from attributes of the user, the data and the situation, such as department or time of day. Many apps combine the two: roles for the broad rules, attributes such as ownership for record-level checks.

### Where should roles be checked in a web app?

On the server or in the database, on every request. Hiding a button stops nobody who calls the API directly. OWASP's authorization guidance says apps must never rely on client-side access control checks. The interface can mirror the rules, but only as a convenience.

### How many roles should a new SaaS app start with?

As few as the product needs, usually an owner or admin, a member and sometimes a read-only viewer. Each extra role is another set of rules to test. Start each role with no rights and add only what it needs, which is NIST's least privilege idea.

### Can RBAC be done with Supabase row-level security?

Yes. Supabase documents storing roles in tables, adding the role to the session token with a custom access token hook, and checking it in row-level security policies through an authorize function. The database then refuses actions a role lacks, even if the interface misses a check.

## Sources

- [NIST: Role Based Access Control project](https://csrc.nist.gov/projects/role-based-access-control)
- [NIST glossary: least privilege](https://csrc.nist.gov/glossary/term/least_privilege)
- [Supabase docs: Custom Claims and Role-based Access Control](https://supabase.com/docs/guides/database/postgres/custom-claims-and-role-based-access-control-rbac)
- [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)