Role-Based Access Control (RBAC): Permissions vs. Roles

Adrienne Domingus
3 min readFeb 19, 2020

Once we’ve determined that a user is who they say they are (authentication), we next need to determine whether they can access the page or resource they’re trying to access (authorization). Role-Based Access Control (RBAC) is one of the most common ways enterprise software accomplishes this. It is highly flexible and allows for any number of configurations.

We’ll talk high level here about what roles and permissions are, how they work together and how we can use them to check for access.

What is a Role?

Roles often align with job functions, but it’s definitely possible that they don’t, depending on our context.

For example, if we’re building an e-commerce site, we might have a full admin who can do things like create new products, change inventory, view orders, fulfill orders, add users, etc.

We might have someone who works in fulfillment who can view and fulfill orders, and perhaps someone else in accounting who should only be able to view orders, but not change anything.

Roles in these examples might be things like admin, fulfillment manager, accounting admin, etc.

A user may also have multiple roles, or, to simplify that process, roles can be hierarchical (one role encapsulates multiple other roles, and thereby contains all the permissions within). This is where that flexibility comes in!

What’s a Permission?

Permissions are specific and resource-based — they define whether or not a person has access to a specific resource. This may be based on either the type of resource, or a specific resource — for example, a user might be able to edit all products, or they may be able to edit only products D and Y.

Using our example from above, examples of permissions might be view product, edit products, view orders, fulfill orders, or add users.

These can be as granular or as broad as necessary, but the more granular they are, the more control we have over who can do what — which after all, is the whole point! And since roles can be assigned multiple permissions, there’s no compelling reason to not err on the side of making them more granular.