Authorization Models: RBAC, ABAC and ReBAC — Authentication & Authorization Architecture

RBAC assigns permissions to roles and roles to users — simple and auditable, but role explosion happens when rules depend on context. ABAC evaluates attributes of the user, resource, action and environment ("managers can approve expenses under $5,000 in their department"). ReBAC (Google Zanzibar style) derives access from relationships ("viewer of a folder can view its documents"), ideal for sharing and hierarchies. Whatever the model: deny by default, enforce on the server for every request, and check object-level access, not just endpoints.

# ReBAC (OpenFGA-style) model
type user
type organization
  relations
    define member: [user]
    define admin: [user]
type folder
  relations
    define owner_org: [organization]
    define viewer: [user] or member from owner_org
    define editor: [user] or admin from owner_org
type document
  relations
    define parent: [folder]
    define can_view: viewer from parent or editor from parent
    define can_edit: editor from parent

Common pitfalls

Checking roles but not ownership (IDOR / broken object-level authorization).
Authorization logic duplicated across services and UI.
Hard-coding role names throughout the code instead of permissions.

Key points

RBAC for simple, ABAC for contextual, ReBAC for sharing/hierarchies
Deny by default; enforce server-side
Always check object-level access

Further reading: OWASP Authorization Cheat Sheet

Practice questions

When does RBAC stop being enough?

Answer

When rules depend on relationships or context — resource ownership, sharing, departments, time or amounts — leading to role explosion. ABAC or ReBAC then express rules more naturally.

What is broken object-level authorization (BOLA)?

Answer

An API checks that the user is logged in but not that they may access the specific object ID requested, so changing an ID exposes other users' data. It's the top OWASP API Security risk.