“Admin” and “User” work until the business asks a real question.
Can a finance manager refund this invoice?
Can a tenant administrator edit users from another tenant?
Can an author update only their own draft?
Roles describe broad identity. Permissions and policies describe actions on resources within a context.
A stronger model checks:
actor + action + resource + context
Avoid scattering <code>user.role === ...</code> checks throughout controllers and services.
When did your application outgrow basic role-based access control?
#NestJS #RBAC #ApplicationSecurity

Welcome to the NestJS Developers Hub, a collaborative community for developers passionate about NestJS! Whether you're a seasoned expert or just getting started, this group is dedicated to sharing knowledge, solving problems, and advancing our skills

Nestjs Developers

Basic role-based access control (RBAC) with 'Admin' and 'User' roles breaks down when real business questions arise — like whether a finance manager can refund an invoice or an author can only edit their own draft. A stronger authorization model evaluates actor + action + resource + context together, rather than scattering role checks across controllers and services.

Day 13/30 — Roles Are Not Enough

Absolutely. You cannot build a broader enterprise system using just roles and permissions.
Real world business scenarios quickly go beyond basic RBAC. When the authorization model cannot express those scenarios, the result is usually hardcoded role checks scattered throughout the application.
At a high level, RBAC answers: “What is this role allowed to do?” including CRUD and other business operations.
But then comes a more important dimension: the data.
What subset of the data is this user allowed to CRUD?
And then there is another dimension: the relationship.
Is this user allowed to perform an action because they own the resource, manage the resource, belong to the same organization, or have some other relationship with it?
So, in practice, enterprise authorization often needs a combination of:
<ul>
<li>RBAC — Role-Based Access Control</li>
<li>ABAC — Attribute-Based Access Control</li>
<li>ReBAC — Relationship-Based Access Control</li>
</ul>
The real authorization decision becomes much closer to:
Actor + Action + Resource + Context + Relationship
That is where simple <code>user.role === ...</code> checks start breaking down—and where a proper authorization model becomes essential.

In my opinion, how you design a system, depends largely on it’s requirements.

Resource ownership belongs in a policy check, not another role with a longer name

For us the axis wasn’t the role, it was the credential. One auth config accepts both a browser session JWT and a developer API key, so the same user identity arrives two ways and only one of them may rotate a key or start a checkout. That check sits in a permission class on 11 view modules, and forgetting it on a new mutation endpoint turns a leaked read-only key into account takeover.