Glossary

RBAC

RBAC maps users to permissions through roles. It keeps access management clear when roles reflect real work and checks are performed on the server.

Short definition

Roles are a shorthand for recurring responsibilities.

Role-Based Access Control (RBAC) organises permissions into named roles. Instead of assigning every permission manually to every user, a warehouse employee might receive a role that allows them to read orders and update fulfilment, while an accountant can view documents and payments.

RBAC addresses authorization: whether an already authenticated user may perform a particular action on a particular resource. It is not authentication. Login establishes who the user is; RBAC decides what they may do. In a multi-tenant system, a role is usually also tied to an organisation or account rather than assigned globally to a person.

Use cases

Where permissions are part of the business rules

The model makes sense when the same responsibilities recur across multiple users.

online-store administration for warehouse staff, customer support, accountants, and administrators
an internal system separating sales, operations, and finance
multi-tenant SaaS where the same user has a different role in each organisation
an administration API that must verify both the action and organisation boundary on the server
auditing permission management, onboarding, and access removal

Practical example

One person, two organisations

Jana is an owner in the Alfa organisation and a reader in Beta. In Alfa, she can assign a warehouse employee and approve order exports. In Beta, she may only read the overview. The application therefore does not maintain a single global role of Jana = owner, but a user–organisation–role relationship.

When a request is made to ship an order, the server first loads the order, identifies its organisation, and only then verifies the order.ship permission within that organisation. The frontend may hide the button for a better user experience, but the same check must run in the API or controller because the request can be sent without the button.

How it works

A simple access-decision flow

Every step needs a clear source of truth and a link to the current organisation context.

The user is authenticated A session or identity provider establishes the identity, not permission to perform an operation automatically.
The application identifies the tenant It determines the account in which the user is working from the URL, selected organisation, or resource ownership.
Current roles are loaded The user–organisation assignment provides one or more roles for the given context.
Roles are mapped to permissions For example, order.read, order.ship, or invoice.export represent specific permitted actions.
The server allows or denies the action The check verifies both the permission and resource ownership; a hidden frontend button is not enough.

Key concepts

The model needs boundaries and operational rules.

Role names should be understandable to both people and code, but should not stand in for every detail of the business rules.

Roles and permissions

A role groups permissions. A permission describes a specific action, such as changing a shipment status. A user can have multiple roles when their combination reflects the job responsibilities.

Default deny and least privilege

An action is allowed only after an explicit check. A new role should not inherit everything for convenience; access is expanded according to a verified need.

System and contextual roles

A global platform administrator and an administrator of a single organisation have different reach. The same person can be an owner in one company and a reader in another.

Auditing and changes

Role assignment, modification, and removal should all leave a traceable record. For sensitive actions, it is worth checking current state rather than relying only on a long-lived token.

Benefits and limitations

Clarity disappears when roles branch for every exception.

Benefits

recurring responsibilities are managed through groups rather than individually per user
server-side checks can be consolidated into clear rules
auditing assignments and removing access promptly are easier
tenant context prevents confusion between organisations

Risks

role explosion caused by many nearly identical roles and exceptions
an overly broad administrator role bypassing least privilege
merely hiding a button failing to protect an API or form
role hierarchy obscuring an unexpected inherited permission

Scope

Roles should reflect work, not menu structure.

Three or four stable roles may be enough for a smaller administration interface. In a more complex system, it is worth separating permissions from navigation display, specifying the organisation boundary, and describing sensitive actions in both code and documentation. When a decision depends mainly on properties of the record itself, time, or a contractual relationship, RBAC may need additional rules.

Roles should not become the sole home for every business exception. An accountant may have invoice.export, for example, but the export still belongs only to the current organisation and may require an additional check of order state. Regular access reviews and auditing are part of the design, not an administrative afterthought.

What to consider

Test permissions at the server boundary.

A secure design accounts for role changes, multiple tenants, and attempts to bypass the user interface.

default denial of access and an explicit permission for each protected action
checks of the tenant and resource ownership alongside the role
consistent permission naming and tests for both allowed and denied paths
auditing role changes and promptly removing access when a person changes position
short-lived or freshly evaluated sensitive permissions instead of blind trust in a long-lived token

Common questions

Using RBAC without false confidence

Does an administrator role always mean unlimited access?

No. An administrator of one organisation does not necessarily manage another tenant or the operational settings of the entire platform. The scope should be named and checked explicitly.

Is a role stored in a JWT enough?

It depends on its lifetime and the risk. After a role is removed, a long-lived token may carry stale information; sensitive actions often require a current evaluation.

Is an OAuth scope a role?

No. A scope defines client access to an interface. A role typically describes the job responsibilities of a user in a particular application or organisation.

When is RBAC not enough?

If a decision depends mainly on resource attributes, the relationship of the user to the resource, or time, RBAC should be supplemented with targeted business rules or another model.

How I design access in practice

Permissions belong at the server and data boundary of the application.

For internal systems, APIs, and e-commerce, I address who may perform a specific action and within which organisation.

Explore my expertise Discuss your project without obligation