Role-Based Access Control

Authentication proves who someone is; RBAC decides what that specific person is allowed to do once they're in — the difference between a support agent viewing a ticket and that same agent issuing a refund.

Roles bundle permissions so access can be granted and revoked by job function, not one permission at a time per person

The principle of least privilege means every role starts with zero access and earns only what the job requires

Privilege escalation bugs happen when an action checks "is logged in" instead of "does this role include this specific permission"

Role changes should be logged and reviewable — permissions quietly drift over time as people change teams

Hands-on demo

Try acting as different roles

Pick a role, then attempt each action — the server checks the role's actual permission set on every request, not just whether you're logged in.

Attempt an action above to see it evaluated against the role's permissions.

Try it yourself

Try it yourself — run a scenario below, then flip this and replay it to see what changes.

Support Agent Views a Ticket

A role with read access to tickets works exactly as intended.

Want this flow explained in detail as it plays?

app.flowground.dev/support

Ticket #4821

CustomerAlex R.

StatusOpen

Support Agent

App

Their account is assigned the "Support Agent" role, which includes the tickets:read permission.

Selected hop

Support agent opens a customer ticket

Support Agent

A staff member with role-scoped access to help customers.

App

The application's backend — enforces business rules and decides what every request is allowed to do.

What happens here

Their account is assigned the "Support Agent" role, which includes the tickets:read permission.