RBAC vs ABAC vs Capability-Based Access Control Explained

RBAC vs ABAC vs capability-based access control comes down to one underlying question asked three different ways: when a system decides whether to let a request through, what is it actually checking? A role, a set of attributes, or the token itself? These aren't competing implementations of the same idea, they're genuinely different answers, each with its own NIST definition, its own real-world trade-offs, and its own failure modes. AIOZ Storage's own macaroon-based access grants, covered in full detail elsewhere in this series, turn out to be a working, production example of the third model, worth understanding on its own theoretical terms rather than just as a product feature.

TL;DR:

• RBAC checks a role: permissions attach to a role, and a user gets whatever that role allows. NIST defines it as identifying "permitted actions on resources... with roles rather than with individual subject identities."
• ABAC checks conditions: NIST defines it as granting or denying 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 itself: seL4's own documentation defines a capability as "a unique, unforgeable token that constitutes a permission to access an entity or object," a pattern AIOZ Storage's bearer-token macaroons fit directly.

Access Control Models: Three Different Questions

Every access control system eventually answers the same question, should this request be allowed, but the three major models get there by checking fundamentally different things. RBAC checks who the requester is, or more precisely, what role they've been assigned. ABAC checks the current situation, attributes of the requester, the resource, and the environment, evaluated against a policy at the moment of the request. Capability-based security skips identity checking almost entirely and checks the credential itself, if you're holding a valid, unforgeable token that authorizes an action, that's sufficient, regardless of who you are.

That's not three ways of implementing one idea. It's three different philosophies about where trust actually lives, in an assigned identity, in a set of conditions, or in a possession.

Role-Based Access Control (RBAC): Permissions Tied to a Role

NIST's own definition is direct: RBAC is "a model for controlling access to resources where permitted actions on resources are identified with roles rather than with individual subject identities." In practice, that means an administrator defines a set of roles, say, editor, viewer, and admin, assigns a fixed bundle of permissions to each role, and then assigns users to roles rather than managing permissions per person. NIST's complementary definition notes that "role permissions may be inherited through a role hierarchy," so a more senior role can build on a junior one instead of duplicating its permission list from scratch.

RBAC's real strength is administrative simplicity at scale: managing a thousand users through a dozen roles is far more tractable than managing a thousand individual permission sets, and NIST's own framing captures why it's the default in most organizations, roles "typically reflect the permissions needed to perform defined functions within an organization," which usually maps cleanly onto how a company actually organizes work.

Attribute-Based Access Control (ABAC): Permissions Tied to Conditions

ABAC replaces the fixed role with a policy evaluated fresh on every request. NIST's SP 800-162 definition states it precisely: 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 or a clearance level; an object attribute might be a document's classification; an environment condition might be the time of day or the requester's network location. The decision comes from combining all three against a policy, not from checking a static role assignment.

That flexibility is also ABAC's real cost. A policy engine evaluating combinations of subject, object, and environment attributes is considerably harder to design, audit, and reason about than a role table, and NIST's own guidance on ABAC implementation treats policy correctness as a genuinely harder problem than RBAC's simpler role-to-permission mapping. ABAC earns its complexity when access genuinely needs to depend on context RBAC's fixed roles can't express, like "only during business hours" or "only from a managed device."

Capability-Based Security: Permissions Tied to the Token Itself

Capability-based security answers the access question completely differently: instead of checking who you are or what conditions apply, it checks what you're holding. The seL4 microkernel's own documentation gives a clean definition: "a capability is a unique, unforgeable token that constitutes a permission to access an entity or object in the system," describing the concept memorably as "a pointer with access rights." The token itself is both the reference to the resource and the proof of authorization to use it, combined into one unforgeable object, rather than authorization being looked up separately based on identity.

That has a real practical consequence: a capability is naturally bearer-based and delegatable. Hand someone the token, and you've handed them exactly the access it grants, no separate identity check, no central authorization lookup required at the moment of use. That's also the model's real risk, since possession alone is sufficient, losing control of a capability token means losing control of whatever it authorizes, with no identity-based backstop checking whether the holder was ever supposed to have it.

Where Capability-Based Security Differs From Both

RBAC and ABAC both fundamentally ask "who is this, and what have they been granted?" before checking a central source of truth, a role table or a policy engine, at request time. Capability-based security doesn't need that central check at all, the token carries its own authorization, cryptographically or structurally, so a system can validate it without a database lookup. That makes capability-based systems well suited to delegation, since handing off a capability, or a narrower, attenuated version of one, doesn't require going back to a central authority to register the new permission relationship the way granting a role or updating an ABAC policy typically would.

The trade-off mirrors the strength: RBAC and ABAC both give an administrator a central place to see and revoke everyone's access at once. A capability-based system, by design, distributes that authorization into tokens that may exist in multiple hands, which is exactly why capability systems put so much design effort into mechanisms for narrowing or expiring a token after it's issued.

How AIOZ Storage's Macaroons Fit the Capability Pattern

AIOZ Storage's access-grant system, covered in full elsewhere in this series, is built on macaroons, bearer tokens carrying their own cryptographic proof of authorization via chained HMAC caveats. That maps directly onto the capability pattern described above: the macaroon itself, not a separate identity check, is what a request presents as proof of authorization, and AIOZ's own documentation describes the underlying design goal in almost the same language capability theory uses, separating "the policy (who can access what) from the mechanism (how the policy is enforced)."

The caveat mechanism is also a real, working answer to capability-based security's central risk: since a macaroon's caveats can only be narrowed, never removed, once issued, an access grant can be attenuated down to a specific bucket, action, and expiration window before it's ever handed to someone else, limiting the blast radius of a lost or over-shared token without requiring a central revocation lookup on every single request. This isn't AIOZ's own stated framing, the plan's own access-control article never uses the word "capability", it's a real, defensible categorization based on what a capability actually is: an unforgeable, bearer-based token that combines a resource reference with the authorization to act on it.

Which Model Fits Your System

The honest way to choose is to ask where trust should actually live in your system. If access maps cleanly onto job functions and rarely needs situational nuance, RBAC's simplicity is usually the right default, and it's what most organizations reach for first. If access genuinely needs to depend on real-time context, time, location, device posture, that a fixed role can't express, ABAC's added complexity earns its keep. If your system's core problem is delegation, letting one party hand off a narrower slice of their own access to another without a central authority mediating every handoff, capability-based security, the pattern AIOZ Storage's macaroons implement, is built specifically for that case in a way RBAC and ABAC aren't.

None of the three is a strictly superior default. Each one answers a genuinely different question about where authorization should live, and the right choice depends on which question your system actually needs answered.

Frequently Asked Questions

What's the difference between RBAC and ABAC?
RBAC grants permissions based on an assigned role, evaluated against a fixed role-to-permission table. ABAC grants permissions based on a policy evaluated against attributes of the subject, resource, and environment at request time, allowing more contextual decisions at the cost of more complex policy design.

What is capability-based access control?
A model where the credential itself, an unforgeable token combining a resource reference with the authorization to act on it, is what proves access, rather than checking identity against a central role or policy table. seL4's own documentation describes a capability as "a pointer with access rights."

Is AIOZ Storage's macaroon system RBAC, ABAC, or capability-based?
Capability-based. AIOZ Storage's macaroons are bearer tokens that carry their own cryptographic proof of authorization via chained HMAC caveats, matching the capability pattern of an unforgeable token combining reference and authorization, rather than checking a role or evaluating attribute policies.

Why is ABAC considered more complex than RBAC?
Because ABAC evaluates a policy against combinations of subject, object, and environment attributes at request time, rather than checking a fixed role assignment. That flexibility makes ABAC policies genuinely harder to design, audit, and reason about than an RBAC role table.

What's the main risk of capability-based security?
Since possession of the token alone grants access, losing control of a capability, through leaking, oversharing, or theft, hands over whatever it authorizes with no identity-based backstop. Systems built this way, like AIOZ Storage's macaroon caveats, invest heavily in mechanisms to narrow or expire a token after it's issued.

Can a system combine RBAC, ABAC, and capability-based access control?
Yes, the three models answer different questions and aren't mutually exclusive. A system might assign broad roles (RBAC), evaluate contextual policies for sensitive actions (ABAC), and use capability tokens like macaroons or access grants for delegated, temporary access to specific resources.

Why do capability systems favor bearer tokens instead of identity checks?
Because a bearer token can be validated using its own embedded cryptographic proof, without a central lookup at request time. That makes capability-based systems well suited to delegation, handing off narrower access without registering the change with a central authority first.

Related Reading

• AIOZ Storage Access Control: Macaroons and Access Grants - the full mechanics of the macaroon and access-grant system that this article gives its proper theoretical context.
• AIOZ Storage Glossary: Bucket, Passphrase, Macaroon - quick definitions for macaroon, caveat, and access grant used throughout this article.
• Managing Team Access and Sub-Users on AIOZ Storage - how AIOZ Storage's own team-access model applies the access-grant system covered here in practice.
• AIOZ Storage Explained: S3-Compatible Decentralized Storage - what AIOZ Storage is overall, including where its access-control model fits.
• Bucket Policy vs IAM Policy: What Is the Real Difference? - AWS's own identity-based and resource-based mechanisms, a concrete contrast to the capability-based model covered here.

References

• NIST CSRC Glossary: Role-Based Access Control
• NIST CSRC Glossary: Attribute-Based Access Control
• seL4 Documentation: Capabilities