Role-Based Access ControlLesson 5.1

RBAC design: roles, permissions, and resource ownership

RBAC definition, role hierarchy, permission granularity, resource ownership model, flat vs hierarchical roles, ABAC comparison, real-world role design

RBAC Design: Roles, Permissions, and Ownership

Role-Based Access Control (RBAC) maps users to roles and roles to permissions. Instead of assigning permissions directly to users, you assign roles, and roles carry permission sets.

Core entities:

Role: Named category of access (admin, editor, viewer, moderator)
Permission: Specific allowed action (post:create, post:delete, user:ban)
Resource: The thing being acted on (a specific post, user account, report)

A simple role model for a blog API:

const ROLES = {
  viewer: ['post:read'],
  editor: ['post:read', 'post:create', 'post:update:own'],
  admin: ['post:read', 'post:create', 'post:update:any', 'post:delete:any', 'user:ban']
};

Resource ownership adds a dimension beyond roles: post:update:own means an editor can update their own posts but not others'. This requires checking both the role permission and whether the authenticated user owns the resource.

Keep roles coarse-grained and permissions fine-grained. Three to five roles covers most apps. If you find yourself creating roles for individual users, switch to Attribute-Based Access Control (ABAC) — RBAC is the right starting point for most teams.