Role-based access control

Role-based access control (RBAC) is a method of assigning permissions to users based on their roles. Consider using RBAC in the following scenarios:

• You have multiple users with different access needs: RBAC is ideal when users need varying permissions based on roles, such as admin, editor, or viewer.
• You need to simplify permission management: It's efficient for managing large groups of users by assigning roles rather than setting permissions individually.
• Your app serves different departments or teams: It's useful in scenarios where different groups require distinct levels of access to resources.

Understand how Role-based access control work

Permissions(Scopes)

Permission refers to the authorization to access a [API resource]. In the real world, entities such as orders, products, and documents can be designated as resources, and various actions can be assigned.

Examples of permissions, including the ability to edit an order, read a document, and delete a product, are as follows:

• write:orders
• read:documents
• delete:products

The above figure shows the permission read:item in resource https://api-1.store.io is different from the permission read:item in resource https://api-2.store.io.

If no API Resource is provided, permission will be treated as "for OIDC". Usually this is not what you want in RBAC.

Roles

Roles are a grouping of permissions that can be assigned to users. They also provide a way to aggregate permissions defined for different APIs, making adding, removing, or adjusting permissions more efficient than assigning them individually to users.

Here's an example of an order_admin role with several permissions for two resources:

It's OK to have permission overlap between roles.

Example: An online bookstore

Let's say you have an online bookstore to manage. Here, we greatly simplify the access control model for demonstration purpose.

The model is divided to two major API Resources: orders and products. They have different resource indicators as below:

• Orders: https://api.store.io/orders
• Products: https://api.store.io/products

For each resource, you'd like to separate permissions into read, write, and delete. So you define six permissions in total:

• https://api.store.io/orders
  • Permission read:order
  • Permission write:order
  • Permission delete:order
• https://api.store.io/products
  • Permission read:product
  • Permission write:product
  • Permission delete:product

Here's the illustration of this model:

You want to have two types of admin, order admin and product admin:

• Order admin can manage orders and see products (as orders consist of products), but cannot manage products.
• Product admin can manage products, and they should not be aware of any orders.

So you create two roles, order_admin and product_admin, with the permissions:

• order_admin
  • https://api.store.io/orders
    • read:order, write:order, delete:order
  • https://api.store.io/products
    • read:product
• product_admin
  • https://api.store.io/products
    • read:product, write:product, delete:product

Here's the illustration of these two roles:

It's OK to assign both order_admin and product_admin to a user, then they will have all six permissions you just defined.

Note the order admin shares the permission read:product with the product admin, and the final permissions that a user holds is the union of all permissions from the roles they has been assigned.