RBAC, ABAC, and ACL

Authentication proves who; authorization decides what they may do on which resource.

| Model | Unit | Best fit | |-------|------|----------| | RBAC | Roles → permissions | Admin panels, coarse product tiers | | ABAC | Attributes (user, resource, env) | Contextual rules ("owner only", time windows) | | ACL | Per-resource grant list | Documents, shared folders |

					// RBAC check
if (!user.roles.includes('editor')) throw forbidden();

// ABAC-style policy
function canEdit(user, document) {
  return document.ownerId === user.id || user.roles.includes('admin');
}
				

Hybrid designs are common: RBAC for defaults, ABAC for exceptions. Keep policy readable and testable — not scattered `if` statements without a named model.

On interviews: when RBAC becomes role explosion; how ABAC handles dynamic conditions; ACL sync cost at scale.

Common pitfalls: checking roles in UI only; superuser flags instead of explicit permissions; authorization after data already fetched (IDOR).

Checklist:

• Separate authn middleware from authz checks.
• Name permissions, not only roles, for fine control.
• Enforce authorization at the resource boundary.
• Unit-test policy tables and edge cases.