RBAC vs ABAC vs Capability-Based Access Control Explained

RBAC vs ABAC vs capability-based access control comes down to what a system checks when a request arrives: a role, a set of attributes, or the token itself. NIST defines RBAC and ABAC. Capability-based security is the model behind AIOZ Storage's macaroon access grants.

TL;DR:

• RBAC checks a role. NIST defines it as a model where "permitted actions on resources are identified with roles rather than with individual subject identities."
• ABAC checks attributes. NIST's SP 800-162 definition grants or denies access "based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies."
• Capability-based security checks the token. seL4 defines a capability as "a unique, unforgeable token that constitutes a permission to access an entity or object."
• AIOZ Storage access grants are macaroons, bearer tokens whose caveats can be added but never removed, which makes them a capability system.

Updated Oct 28, 2026: shorter opening, question headings, a labelled diagram, AWS's RBAC vs ABAC example, and a section on AIOZ Storage members and grants.

Three Models, Three Questions

Every access control system decides whether a request may go through, but the three main models check different things. RBAC asks which role you hold. ABAC asks what is true right now about you, the resource and the environment, and evaluates that against a policy. Capability-based security barely asks who you are: if you hold a valid, unforgeable token for an action, that is enough.

So the real difference is where trust lives: in an assigned role, in a set of conditions, or in something you possess. The diagram below puts the three side by side.

Role-Based Access Control (RBAC)

NIST defines RBAC as "a model for controlling access to resources where permitted actions on resources are identified with roles rather than with individual subject identities." In practice, an administrator defines roles such as editor, viewer and admin and gives each role a fixed bundle of permissions. Users are then assigned to roles instead of getting permissions one by one. NIST's second definition adds that "role permissions may be inherited through a role hierarchy," so a senior role can build on a junior one.

RBAC's strength is simple administration at scale. Managing a thousand users through a dozen roles is far easier than managing a thousand separate permission sets. NIST also notes that roles "typically reflect the permissions needed to perform defined functions within an organization," which is why RBAC maps so neatly onto how most companies are organized.

Attribute-Based Access Control (ABAC)

ABAC replaces the fixed role with a policy that is evaluated on every request. NIST SP 800-162 says access is "granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions." A subject attribute might be a department, an object attribute a document's classification, and an environment condition the time of day or the network a request comes from.

AWS IAM gives a concrete version. AWS calls attributes tags, and you can write policies "that allow operations when the principal's tag matches the resource tag." In AWS's example, three IAM roles carry the tag key access-project with the values Heart, Star and Lightning, and a single policy grants access whenever the role's tag value matches the resource's.

What Is the Difference Between RBAC and ABAC?

RBAC decides from a role table that changes only when an administrator edits it. ABAC decides from a policy evaluated against live attributes, so you get more context in the decision and more work in designing the policy.

AWS's IAM guide shows the trade-off with that same project example. Under RBAC you create one role per project and attach a policy listing the resources it can reach. When the Star project needs a new EC2 container, you "have to update the policy attached to the Star IAM role," or Star members can't use it. Under ABAC, a resource created with the right tag is covered by the existing policy. AWS sums it up as "ABAC requires fewer policies."

The cost is that an ABAC policy is harder to read and audit than a role table. When access needs to depend on context a fixed role can't express, such as "only during business hours" or "only from a managed device," that cost is worth paying. When it doesn't, RBAC is easier to reason about.

What Is Capability-Based Access Control?

Capability-based security checks what you hold instead of who you are. The seL4 microkernel's documentation defines a capability as "a unique, unforgeable token that constitutes a permission to access an entity or object in the system." It suggests you think of it "as a pointer with access rights." The token is both the reference to the resource and the proof that you may use it.

That makes capabilities bearer-based and easy to delegate. If you hand someone the token, you've handed over exactly the access it grants, with no identity check and no central lookup when they use it. It's also the main risk: whoever holds a leaked token gets what it authorizes, and there's no identity check to notice they were never meant to have it.

How Capabilities Differ From Roles and Policies

RBAC and ABAC both consult a central source of truth at request time, either a role table or a policy engine. A capability carries its own authorization, so a system can validate it without a database lookup. That suits delegation, because handing off a capability, or a narrower version of one, doesn't require registering a new relationship with a central authority.

The trade-off mirrors the strength. RBAC and ABAC give an administrator one place to see and revoke everyone's access. A capability system spreads authorization into tokens that may sit in many hands, which is why capability designs work so hard on narrowing and expiring tokens after they're issued.

Which Access Control Model Should You Use?

Start by asking where trust should live in your system. If access follows job functions and rarely needs situational detail, RBAC is the sensible default, and it's what most organizations reach for first. If access must depend on real-time context such as time, location or device posture, ABAC's extra complexity pays off. If your main problem is delegation, letting one party hand a narrower slice of its access to another without a central authority in the middle, capability-based security is built for that case.

You can also combine them. Many systems give people broad roles, add attribute conditions for sensitive actions, and use short-lived tokens for delegated access to specific resources.

How AIOZ Storage Handles It

AIOZ Storage uses two layers. Members are named logins under your account, and for each bucket you assign them a permission of All, Read, Write, List or Delete. That's per-identity permission, not RBAC, since the docs describe no roles or groups.

Access grants are the capability layer. The docs call macaroons "bearer tokens that enable applications to ascertain whether their holders' actions are authorized." Their caveats "are constructed using chained HMAC functions, allowing easy addition of caveats while preventing their removal." So you can narrow a grant to one bucket, a set of actions and an end date before you share it. The docs even describe the goal the way capability theory does: macaroons "separate the policy (who can access what) from the mechanism (how the policy is enforced)." AIOZ doesn't use the word "capability" itself; the label is ours, based on the seL4 definition above. For the full mechanics, see how AIOZ Storage macaroons and access grants work.

Revocation follows the capability pattern too. You revoke a grant by deleting it in the console. Deleting a primary grant also invalidates every child grant derived from it on the client side, because AIOZ Storage doesn't know those children exist. Once you've created a grant with Read and List, the AIOZ CLI guide's listing command shows what that token can see:

aws s3 --endpoint-url https://s3.aiozstorage.network ls s3://bucket-name

What the docs don't cover yet (checked Oct 28, 2026):

• Roles or groups for members, or attribute and tag conditions
• Revoking one child grant without deleting its parent (the Revocation page says this is coming in "upcoming versions")

To create a grant with only the permissions a job needs, follow the Manage Access Grants guide.

Frequently Asked Questions

What's the difference between RBAC and ABAC?
RBAC grants permissions through an assigned role and a fixed role table. ABAC evaluates a policy against attributes of the subject, resource and environment on each request, which allows more context but makes policies harder to design and audit.

What is capability-based access control?
A model where an unforgeable token that names a resource and carries the right to act on it is the proof of access. The seL4 docs describe a capability as "a pointer with access rights."

Is AIOZ Storage's macaroon system RBAC, ABAC or capability-based?
Capability-based. Macaroons are bearer tokens that carry their own cryptographic proof, and their caveats can be added but not removed. AIOZ Storage members, by contrast, get per-bucket permissions with no roles.

Why is ABAC considered more complex than RBAC?
Because it evaluates combinations of subject, object and environment attributes on every request instead of checking a fixed role. Those policies are harder to write, test and audit than a role table.

What's the main risk of capability-based security?
Possession is enough, so a leaked token hands over whatever it authorizes. That is why capability systems, including AIOZ Storage's macaroons, narrow and expire tokens before sharing them.

Can a system combine RBAC, ABAC and capabilities?
Yes. A system can assign broad roles, add attribute conditions for sensitive actions, and issue capability tokens for delegated, temporary access to specific resources.

When should you choose ABAC over RBAC?
When new resources appear often or access depends on context. AWS's example shows ABAC covering a new tagged resource without a policy edit, while RBAC needs the role's policy updated.

Related Reading

• AIOZ Storage Access Control: Macaroons and Access Grants - the full mechanics of the capability layer described here.
• AIOZ Storage Glossary: Bucket, Passphrase, Macaroon - quick definitions for macaroon, caveat and access grant.
• Managing Team Access and Sub-Users on AIOZ Storage - how members and per-bucket permissions work in the console.
• What Is AIOZ Storage? S3-Compatible Decentralized Storage - the product as a whole.
• Bucket Policy vs IAM Policy vs ACL: When to Use Each - AWS's identity-based and resource-based policies, a contrast to tokens.

References

• NIST CSRC Glossary: Role-Based Access Control
• NIST CSRC Glossary: Attribute-Based Access Control
• AWS IAM: Define Permissions Based on Attributes with ABAC
• seL4 Documentation: Capabilities
• AIOZ Storage Docs: Macaroons
• AIOZ Storage Docs: Revocation