← Back to Users and Identity

Users and Identity

Design Roles and Permissions Around Resources Not Job Titles

8 min read

Permission models should be resource-action pairs enforced server-side, not role names checked only on the frontend.

Rule

Authorization must be resource-action based and enforced exclusively on the server.

Why

Role names like admin change meaning over time. Resource-action permissions are explicit and auditable.

Must

  • Model permissions as resource:action pairs (content:publish, users:delete).
  • Enforce every permission check on the server, not just in UI guards.
  • Assign permissions to roles, not directly to users where possible.
  • Store permission grants with timestamps and granted-by references.

Should

  • Support role inheritance for hierarchical access.
  • Provide an admin UI for viewing effective permissions per user.

Anti-patterns

  • Checking isAdmin in frontend components as the only guard.
  • Storing all roles as a single comma-separated string.
  • No way to audit who has access to what.

Test Cases

  • Direct API call without token is rejected with 401.
  • Valid token with insufficient permissions is rejected with 403.

Telemetry

  • permission_denied
  • role_assigned
  • permission_escalation_attempt