RBAC, ABAC, and ReBAC: Direct Definitions

Role-Based Access Control (RBAC)

RBAC assigns users or workloads to roles such as viewer, editor, billing-admin, or security-analyst. Roles imply permissions. NIST's RBAC work describes access mediated through organizational identities called roles.

Attribute-Based Access Control (ABAC)

NIST SP 800-162 defines ABAC as authorization based on evaluating attributes of the subject, object, requested operation, and sometimes the environment against policy. Examples include department, tenant, data sensitivity, device state, network zone, account tier, and time of day.

Relationship-Based Access Control (ReBAC)

ReBAC derives access from relationships such as “Alice is a member of Team A,” “Team A owns Project 7,” and “Document 42 belongs to Project 7.” Systems in the Zanzibar family represent these relationships directly and evaluate whether a permission follows from the graph.

RBAC vs ABAC vs ReBAC: Side-by-Side

When RBAC Works Well for APIs

RBAC is effective when the application has a small, stable set of job functions and permissions apply broadly. Internal admin APIs, operational tools, and simple SaaS products often start with roles such as viewer, editor, administrator, and billing manager.

subject.roles = ["billing-admin"]
request.action = "refund"
request.resource = "invoice:8291"

allow if:
  "billing-admin" in subject.roles
  AND action == "refund"

The weakness appears when the same role means different things for different resources. “Editor of Workspace A” and “Editor of Workspace B” can lead to role-per-tenant or role-per-project proliferation. RBAC also needs additional logic for conditions like “only during business hours” or “only if the document belongs to the user's region.”

Good RBAC design

• Keep the role catalog small and aligned with stable business functions.
• Separate roles from direct object identifiers where possible.
• Do not put every exception into a new role.
• Still perform object and tenant checks after role evaluation when the resource boundary matters.

When ABAC Works Well for APIs

ABAC is useful when access depends on context that changes across requests. NIST SP 800-162 explicitly models subject, object, operation, and environmental attributes.

allow if:
  subject.department == "finance"
  AND subject.tenant_id == resource.tenant_id
  AND resource.classification != "restricted"
  AND request.action == "read"
  AND environment.device_trust == "managed"

This avoids creating roles such as finance-reader-managed-device-eu. Instead, policy evaluates authoritative facts at decision time.

The hard part is attribute trust

ABAC quality depends on attribute provenance, freshness, and semantics. If an API trusts a client-supplied department=finance header, the model is not secure. Attributes should come from authoritative identity, resource, policy, or environmental sources and have clearly defined ownership.

ABAC can become difficult to reason about when many policies overlap. Build decision explanations, test policy combinations, and avoid hidden default-allow behavior.

When ReBAC Works Well for APIs

ReBAC is especially useful when permission follows the resource graph: organizations contain teams, teams contain projects, folders contain documents, repositories belong to organizations, or resources are shared directly with users and groups.

Google's Zanzibar paper describes a uniform model for storing and evaluating access-control relationships across large services. Modern ReBAC implementations such as OpenFGA use relationship tuples and models to answer questions such as whether a user can view a specific document.

Relations:
user:alice member organization:acme
organization:acme owner project:phoenix
project:phoenix parent document:roadmap

Permission rule:
document viewer if
  direct viewer
  OR viewer of parent project
  OR member of owning organization

This is a natural way to model sharing and inheritance. It also supports reverse questions such as “which documents may Alice access?” without inventing a separate role for every object.

ReBAC is not automatically dynamic-context policy

Time, device posture, risk score, source network, and data classification may still fit better as conditions or attributes. Many relationship engines therefore combine graph-based authorization with contextual conditions.

Why Hybrid Authorization Models Are Common

A realistic SaaS API might use all three models in one decision:

The goal is not to maximize model sophistication. It is to express rules in the representation that matches the business concept:

• Use roles for stable job functions.
• Use relationships for ownership, membership, hierarchy, and sharing.
• Use attributes for context and policy constraints.

A hybrid design also avoids “role explosion,” where every combination of tenant, project, region, device, and permission becomes another role.

How to Implement API Authorization Architecture

Regardless of model, separate decision logic from enforcement clearly enough that every API path behaves consistently.

Do not expect an API gateway to know everything. Gateways are excellent for authentication, scopes, routing, and broad policy. Object-level decisions often require application data or a dedicated fine-grained authorization service.

Consider consistency and caching

Authorization data changes. A removed team membership, revoked share, or changed classification should take effect within a defined window. Cache decisions only when you understand the stale-access risk, include all relevant decision inputs in the cache key, and define invalidation behavior.

How to Choose RBAC, ABAC, ReBAC, or a Hybrid

Prototype the difficult authorization questions before selecting technology. Ask “Why may this user perform this action on this exact object?” for real cases: direct sharing, team inheritance, tenant switching, support access, delegated agents, temporary access, and revocation.

Common API Authorization Mistakes

OWASP API1:2023 Broken Object Level Authorization is a reminder that authorization must be evaluated on the specific object. Ammune's BOLA guide covers object-level API failure patterns in more depth.

Use Runtime Evidence to Validate Authorization Assumptions

Authorization engines make deterministic decisions from known inputs. Runtime API monitoring can reveal patterns that suggest policy or implementation gaps: one user cycling through many object IDs, a service accessing a new tenant, large response sets after a role change, or an allowed operation used in an abnormal business sequence.

Runtime detection does not replace authorization. It provides evidence that the implemented rules match real production behavior and helps investigate when a valid identity appears to act outside the expected access graph.

API Authorization Design Checklist

1. List the hardest real access questions before choosing a model.
2. Use RBAC for stable business roles, not every resource/context combination.
3. Use ABAC when decisions depend on authoritative subject, object, action, or environment attributes.
4. Use ReBAC when access follows ownership, membership, sharing, or resource hierarchy.
5. Combine models when the business rule genuinely combines these concepts.
6. Keep object and tenant authorization server-side.
7. Define authoritative sources for roles, attributes, and relationships.
8. Use consistent PDP/PEP or equivalent decision/enforcement patterns.
9. Fail closed for required decisions and define availability behavior.
10. Design cache keys and invalidation around revocation requirements.
11. Test direct and inherited access, revocation, tenant switching, sharing, and privileged support paths.
12. Monitor runtime API behavior for authorization anomalies and sensitive-response exposure.

RBAC vs ABAC vs ReBAC FAQ

Conclusion

Choose authorization models based on the shape of your permissions. Roles are strong for stable job functions, attributes for dynamic context, and relationships for ownership, hierarchy, and sharing. Keep the model as simple as the business allows, combine approaches when necessary, and enforce authorization on the exact API resource—not merely on the endpoint or token.

References

• NIST SP 800-162 — Attribute Based Access Control
• NIST Model for Role-Based Access Control
• Google Research — Zanzibar
• OpenFGA — Relationship-Based Access Control