Authorisation models: RBAC, ABAC, ReBAC
When roles stop scaling, when attributes get messy, and why Google built Zanzibar. How to pick a model and where the policy engine sits.
● Must know for interviews🔒 PROLesson·26 min read·Intermediate → Staff
authorisationRBACABACReBACOPA
01Three models
✓What you will learn
- Choose RBAC, ABAC or ReBAC for a given product
- Place the policy decision point and keep it fast
- Avoid role explosion and policy sprawl
- Explain Zanzibar-style relationship tuples
| Model | Decision input | Shines | Breaks |
|---|---|---|---|
| RBAC | user → roles → permissions | Internal tools, small permission sets | Per-resource sharing, tenant nuance, role explosion |
| ABAC | attributes of subject, resource, action, environment | Compliance rules: region, classification, time | Debuggability; attribute sourcing at request time |
| ReBAC | relationships: user is editor of doc; doc in folder; folder in org | Sharing, hierarchies, multi-tenant SaaS | Needs a dedicated store; consistency ('new enemy' problem) |
FigA policy decision point with cached decisions
- ACTOR
- SERVICE
- DATA
- STREAM
- Live flow
- Lookup / async
This is an advanced module
Identity & Access Engineering is part of the Pro pass. 1 more section — the deep dives, the final design, follow-ups and the test — unlock with it.
Already a cyart.io or studio.cyart.io member? Your pass code is in your Studio account.