Role-Based Access Control for Web Applications

Most web applications have users who should not all see or do the same things. A customer should see only their own orders, a support agent should not change billing settings, and an administrator needs tools nobody else should touch. Role-based access control is the most common way to manage this. It groups permissions into roles, assigns roles to users and checks those permissions every time someone tries to do something. Done well, it keeps access predictable and auditable. Done poorly, it leaves gaps that attackers and curious users find quickly. This guide explains how to design roles, enforce permissions on the server, handle tokens safely and review access over time.

Authentication and authorisation are different

Two questions sit behind every request:

• Authentication: who is this user?
• Authorisation: what is this user allowed to do?

Login systems, single sign-on and tokens answer the first. Role-based access control answers the second. Many security problems come from treating a successful login as permission to do anything, or from checking permissions only in the user interface.

How role-based access control works

Role-based access control, often shortened to RBAC, has three main parts:

• Permissions: specific actions on resources, such as view invoice, edit customer or delete user
• Roles: named groups of permissions, such as viewer, editor, support agent or administrator
• Assignments: which users hold which roles, sometimes within a scope such as a team or account

When a user makes a request, the application checks whether any of the user's roles grants the permission needed for that action on that resource.

Follow core authorisation principles

The OWASP Authorization Cheat Sheet recommends several principles that apply directly (OWASP Authorization Cheat Sheet):

• Enforce least privileges, giving users only the access they need
• Deny by default, so anything not explicitly allowed is refused
• Validate permissions on every request, not just at login or page load

The same cheat sheet also suggests preferring attribute- and relationship-based access control over pure RBAC where appropriate, which is discussed below.

Design roles around real jobs

Start from the jobs people do, not from features:

1. List user types and what each needs to accomplish
2. List resources and actions in the application
3. Map which actions each user type needs
4. Group these into a small number of roles
5. Review with the people who will hold each role

Avoid creating a new role for every small difference. Too many roles become as hard to manage as individual permissions.

Worked example: a role-based access control matrix

The table below shows a hypothetical permission matrix for a client portal. Roles and permissions are illustrative.

PermissionClient userClient adminSupport agentFinancePlatform adminView own company's ordersYesYesYes, for assigned clientsYesYesCreate ordersYesYesNoNoNoManage company usersNoYes, own company onlyNoNoYesView invoicesNoYesNoYesYesIssue refundsNoNoNoYes, with approvalNoChange platform settingsNoNoNoNoYesView audit logsNoNoNoNoYes

The matrix makes gaps and excess access visible. Note that several cells depend on scope, such as "own company only", which pure roles cannot express alone.

Add scope and ownership checks

Roles say what kind of action is allowed; scope says on which records. A client admin should manage users only in their own company. A support agent should see only assigned clients. These checks must be applied to every query and action, for example by filtering on the user's company ID on the server.

Missing ownership checks are a common source of serious vulnerabilities, where changing an ID in a URL reveals another customer's data. Our guide to client portal user management covers how to structure users, companies and permissions in portals.

Enforce permissions on the server

The user interface can hide buttons, but it cannot enforce security. Every API endpoint and server action must check permissions itself:

• Use a central authorisation function or middleware rather than scattered checks
• Check both the permission and the resource scope
• Return a refusal by default when no rule matches
• Log refused attempts for monitoring

Handle tokens safely

Many web applications use JSON Web Tokens to carry identity and sometimes role information. RFC 7519 defines a JWT as a compact, URL-safe means of representing claims to be transferred between two parties (RFC 7519). RFC 8725, the JWT best current practices document, describes attacks such as changing the algorithm to "none" and recommends practices including performing algorithm verification, validating issuer and subject, and using and validating audience (RFC 8725).

Practical points:

• Use a well-maintained library and allow only the algorithms you expect
• Validate expiry, issuer and audience on every request
• Keep tokens short-lived and support revocation for sensitive sessions
• Consider loading current roles from the server rather than trusting roles embedded in old tokens, so role changes take effect promptly

Know when RBAC is not enough

Pure roles struggle with rules such as "managers can approve expenses for their own team under a set amount" or "users can edit documents shared with them". Attribute-based access control uses properties of the user, resource and context; relationship-based access control uses links such as ownership or sharing. Many applications combine roles for broad access with attribute or relationship checks for fine-grained rules.

Protect administrator roles

Administrator roles deserve extra care because a single compromised admin account can expose everything. Keep the number of administrators small, require stronger authentication such as multi-factor login for them, separate day-to-day accounts from admin accounts where practical, and log every admin action. Consider time-limited elevation, where a user requests admin rights for a specific task and they expire automatically afterwards.

Review access regularly

Access drifts over time as people change jobs and roles accumulate:

• Review role assignments periodically, especially for admin roles
• Remove access promptly when people leave or move
• Track who granted each role and when
• Audit permission changes and refused requests

Our guide to CRM security describes access reviews and permission design for business systems more broadly.

Test authorisation thoroughly

Include authorisation in automated tests:

• For each role, test allowed and refused actions
• Test cross-account access by trying to reach another tenant's records
• Test with expired and tampered tokens
• Re-run tests when adding features or roles

Frequently Asked Questions

What is role-based access control?

It is a way of managing permissions by grouping them into roles, assigning roles to users and checking those permissions whenever a user tries to perform an action.

What is the difference between authentication and authorisation?

Authentication confirms who a user is. Authorisation decides what that user is allowed to do. Both are needed on every request.

Should roles be stored in JWTs?

They can be, but tokens should be short-lived and validated properly. Many applications load current roles on the server so changes take effect immediately.

When should I use ABAC instead of RBAC?

When access depends on attributes or relationships, such as team, amount, ownership or sharing, that roles alone cannot express. Many systems combine both.

Build access control you can trust

We design roles, permission matrices, server-side checks and token handling for web applications and portals. See our custom app development services, or talk to us about access control.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.