IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
RBAC, ABAC & ReBAC — access models
Maya, Sam and Priya share one document workspace. The app must decide what each person may do. Authorization is that decision. Your goal: pick the right model for a feature: roles, rules or relationships.
- Authentication proves who you are. Authorization decides what you may do.
- RBAC gives permissions by job role. Too many exceptions cause role explosion.
- ABAC uses rules over live facts. It is hard to list "who has access".
- ReBAC uses links such as owner and shared-with. It fits sharing.
- Real systems mix all three.
The question is always the same: "Can Sam edit doc:report?" Each model finds the answer by a different route.
RBAC: access by job role
Role-based access control (RBAC) puts permissions into roles. Then it gives roles to people. Priya gets editor. Maya gets viewer. Sam gets nothing until someone grants it. It is simple and easy to audit. An office ID card works this way: the card shows your job, and your job decides which doors open.
It fails when people need something narrower. Priya needs finance files only, Europe only, this quarter only. So someone makes a role called editor_finance_emea_temp_v2. Then another. This is role explosion: hundreds of narrow roles that nobody dares to delete.
a key ring. Everyone in a job gets the same ring. When someone needs a slightly different ring, you cut a new one. Soon you own ten thousand nearly identical rings.
ABAC: access by rules
Attribute-based access control (ABAC) drops fixed roles. It writes rules over attributes. An attribute is a fact about the user, the resource or the situation. A rule might say: "Allow edit if the departments match and it is business hours." No special role is needed. A bank locker is similar: it opens only when your key, the bank's key and the bank hours all agree.
ABAC fits live facts like time, device and how sensitive the data is. Zero trust uses the same signals. But ABAC is weak at one question: "who can edit this?" There is no list to read. The answer is "anyone who passes the rule right now". You must test every user. ABAC is good at deciding, but awkward at auditing.
ReBAC: access by links
Relationship-based access control (ReBAC) answers with a graph of links. Maya owns doc:report. The report sits in folder:q3. Maya shares it with Sam as editor. Now Sam can edit. A link decided it, not a role or a rule. This is the "Share" button of a docs app. Think of sharing a Google Drive folder with your family. Access also passes down: share the folder, and every file inside comes along.
Sam needs to comment on one report and nothing else. With RBAC, you make a role like commenter_partner_report4411, and it outlives the project. With ReBAC, Maya shares that one file with Sam. That is one link. To take it back, you delete the link.
Which one to use
Use RBAC for job-shaped access, such as "engineers can deploy". Use ABAC for live facts. Use ReBAC for sharing. Mature systems mix all three.
| Model | Works well when… | Hurts when… |
|---|---|---|
| RBAC | Access is broad, steady and job-shaped | Exceptions pile up and roles explode |
| ABAC | The answer depends on live facts | You must list who can reach something |
| ReBAC | Access is about ownership and sharing | The rule is about conditions, not links |
The next lesson shows how to draw the relationship graph. Fine-grained authorization later shows ReBAC protecting real product data.
Go deeper: where the models come from
NIST describes RBAC like this: list what each job must do, and let each role carry those rights. NIST SP 800-162 describes ABAC as checking facts about the user, the resource and the setting against rules.
ReBAC comes from Google's 2019 Zanzibar paper. It built the "Share" button of Google's apps into one security system.
A common mix: RBAC for the org chart, ABAC for guardrails such as device and time, ReBAC for sharing.
🧪 Interactive lab — enable JavaScript to play with this one.
Want help choosing an authorization model for your product? Talk to our team.