1 min lesson
RBAC vs ABAC and centralizing the decision
Compare two rows from "RBAC vs ABAC and centralizing the decision", then say when each one fits.
Step 1 of 2
RBAC vs ABAC and centralizing the decisionmake authz hard to forget
- Model
- RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. Press Enter for the full definition.
- Decision is based on
- The user's role (admin, member, viewer)
- Fits when
- Coarse, stable permission sets; easy to reason about and audit
- Model
- ABAC
- Decision is based on
- Attributes of user + resource + context (owner, tenant, time, IP)
- Fits when
- Fine-grained or per-object rules; multi-tenant ownership checks
| Model | Decision is based on | Fits when |
|---|---|---|
| RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. Press Enter for the full definition. | The user's role (admin, member, viewer) | Coarse, stable permission sets; easy to reason about and audit |
| ABAC | Attributes of user + resource + context (owner, tenant, time, IP) | Fine-grained or per-object rules; multi-tenant ownership checks |
Real systems blend both: RBAC for what features you see, ABAC for which rows you may touch.
The design that survives is one where authorization is a single chokepoint every request flows through - a policy layer, middleware or a can(user, action, resource) helper. Scattered if user.is_admin checks rot: someone adds an endpoint and forgets one. Centralize the decision so the default is deny and forgetting it fails closed.