Back to roadmap
Module 9 · Protocols, Security, ObservabilityDay 08525 min

Authorization: RBAC and ABAC

Who can do what, decided where.

Day 085

Authorization: RBAC and ABAC

User
client
API
service
Policy engine
service
Data
datastore
Signal path
Policy engine evaluating attributes
User
client
flow
API
service
API
service
flow
Policy engine
service
API
service
flow
Data
datastore
Memory hook

Authorization: RBAC and ABAC: who can do what, decided where

Mental model

design for the day something breaks

Design lens

RBAC is simple but coarse.

Recall anchors
RBACABACEngines

Why it matters

RBAC assigns roles to users and permissions to roles. ABAC evaluates attributes (user, resource, action, env) against policies. Real apps mix both, often with policy engines (OPA, Casbin).

Deep dive

Centralized engines simplify audit but add latency.

Embed checks at the data layer to prevent IDOR (insecure direct object reference).

Always authorize on server — never trust client claims.

Demo / scenario

Multi-tenant SaaS access checks.

  1. Roles: owner, admin, viewer.
  2. Attribute: tenant_id matches resource.
  3. Policy: viewer can read but not delete; admin can delete within tenant.
  4. Engine evaluates policy at API entry.

Tradeoffs

  • RBAC is simple but coarse.
  • ABAC is flexible but harder to audit.
  • Engine adds infra; co-locate or embed for low latency.

Diagram

User
API
Policy engine
Data
Policy engine evaluating attributes.

Mind map

Check yourself

Loading quiz…

Sources & further reading