Role-Based Access Control assigns permissions through roles.

Example roles may include admin, editor, and viewer.

RBAC is simple and useful when permissions map cleanly to organizational roles. However, real applications often require more context than a role can express.

For example, an editor may edit documents only inside their own organization. A global role check cannot express that relationship by itself.

Authorization must often consider the resource being accessed.

For example, GET /projects/42 should not simply verify that the user has project:read. It should also verify that project 42 belongs to an organization the user can access.

A common security vulnerability is an IDOR/BOLA problem: a user changes /users/42 to /users/43 and gains access to another user's resource because the API checks authentication but not ownership.

OAuth scopes provide coarse-grained permissions such as orders:read or orders:write.

Attribute-Based Access Control can evaluate attributes of the user, resource, action, and environment. For example: allow update when user.organizationId === resource.organizationId and resource.status !== 'locked'.

In complex systems, authorization becomes a policy decision rather than a simple role comparison.