The authorization alphabet soup: What do all these letters mean?

In the identity and access management space, there are a LOT of acronyms. ABAC, PBAC, RBAC, ReBAC. Learn what they mean and how they're used.

David Brossard   ·   Wednesday, April 30th, 2025   ·   Reading Time: 8 minutes

Whether you’re a seasoned expert or a complete beginner in the identity and access management (IAM) space, you’ve most likely noticed that there are a LOT of acronyms. ABAC, PBAC, RBAC and even ReBAC, just to name a few. And then, of course, there’s ZT, ZSP, IGA, and more. Let’s not forget the notorious mandatory access control (MAC) & discretionary access control (DAC).

You may have found yourself staring at a screen that looks like a jumbled up mess of alphabet soup and wondering — do these letters even mean anything?

The answer: they do! In fact, they’re actually quite important when it comes to understanding how organizations safeguard their sensitive data

By breaking down this “alphabet soup”, we can get a better perspective on the distinct advantages each model offers. From dynamic, attribute-driven permission to relationship-based structures, it’s easier to understand how they interconnect to create a strong security framework when we break the acronyms down into basics.

Attribute-based access control (ABAC)

ABAC safeguards data in complex architectures by dynamically granting access based on attributes like location, role, time, device, and actions. Attributes must align with a policy to enforce secure, real-time authorization. ABAC offers advantages such as simplified, policy-driven authorization, granular, context-aware security, data integrity, and regulatory compliance. For instance, it can restrict access based on conditions like location or device type.

ABAC easily tackles complex authorization needs through the mapping of policies and attributes. Its components include subjects (e.g., user roles), actions (e.g., read or write), resources (e.g., data files), and environmental attributes (e.g., time or location). Policies, often expressed using the eXtensible Access Control Markup Language (XACML) standard, combine attributes across systems for seamless workflows.

While other acronyms may come and go, ABAC is one that is analogous to the rest. Each may emphasize different factors — relationships, roles, policies, and trust — but ABAC’s attribute-driven approach enables dynamic, context-aware decisions that closes the gaps left behind other models. Axiomatics specializes in tailoring ABAC solutions to secure critical assets, integrating diverse attributes for robust and adaptive authorization.

Policy-based access control (PBAC)

PBAC allows organizations to swiftly adapt entitlements to new regulations or policies without re-auditing roles, ensuring both compliance and security. Unlike static authorization models like role-based access control (RBAC), PBAC governs access through centralized policies, empowering business owners to manage data securely. PBAC is used interchangeably with ABAC, as both use attributes to enforce policies. The key difference in this sense is which “end” of the access control model stack you look at: policies that inform the authorization engine what to do (PBAC) and attributes that inform the authorization engine how to do it (ABAC).

PBAC is particularly suited for large organizations with complex authorization needs, where roles alone cannot ensure secure access to sensitive data. Implementing PBAC involves starting with high-need areas, externalizing policies to centralized servers and utilizing automated reporting for compliance.

A quick search on Google Trends shows that PBAC is not a commonly used term. ABAC is the more widely accepted term.

Role-based access control (RBAC)

RBAC is ideal for coarse-grained authorization, often used for web access management, securing less sensitive assets or those accessed by many users. Roles are defined by permissions tied to duties, such as clerks, accountants, and managers in an organization. While RBAC is intuitive and simple to implement, it can lead to “role explosion” as roles multiply to accommodate complex scenarios, potentially causing segregation of duty (SoD) failures.

To address these challenges, combining RBAC with ABAC offers a hybrid solution for more fine-grained and dynamic authorization. For example, ABAC can add conditions to restrict certain permissions, like ensuring department managers cannot approve their own transactions. As organizations evolve, they may need to transition from RBAC to ABAC to manage complexity while maintaining usability and security. Tools like Axiomatics enable this transition seamlessly by extending RBAC with ABAC for robust access control.

Relationship-based access control (ReBAC)

ReBAC centers on granting access based on relationships between entities, such as ownership or group membership. Coined by Carrie Cates in 2007, ReBAC complements other access control models like RBAC and ABAC. While RBAC focuses on roles and ABAC emphasizes attributes, ReBAC defines access through static relationship structures, often utilizing graph-based technologies or tuples. Relationships, both direct (e.g., ownership) and indirect (e.g., shared department), are key paths for determining access.

Though ReBAC is great for relationship-based use-cases, it’s limited to “static” relationships and cannot easily handle context or more advanced conditions. ABAC can aid these issues by integrating attributes and a policy language, enabling more nuanced conditions — like restricting document deletion based on publication status.

When combined with ABAC, ReBAC supports fine-grained, context-aware, and flexible access control. Attributes expand ReBAC’s capabilities by introducing dynamic contexts, such as conditions on document status or time.

Token-based access control (TBAC)

Relatively new, token-based access control (TBAC) was coined in 2025 and focuses most on the complex data inside tokens and uses context around the environment to make real-time decisions.

TBAC introduces the notion that attributes alone are not enough to fuel authorization models like ABAC and PBAC. Tokens offer a much richer source of information including provenance of the data, its freshness, integrity, and trustworthiness. Being able to use tokens as a basis for authorization enhances the quality of the authorization and enables scenarios such as access delegation and non-human identity (NHI) or machine identity-driven authorization use cases. TBAC is orthogonal to ABAC and PBAC.

Ultimately, TBAC is an attempt to provide finer-grained authorization in environments that already use tokens (OAuth-based systems) for their applications. Rather than using a PEP/PDP approach as advocated in ABAC and PBAC, access is still being determined in the app by introspecting the token.

Any salt & pepper in the soup? Behold MAC & DAC.

What is Mandatory Access Control (MAC)?

According to NIST’s glossary, MAC is an access control policy that is uniformly enforced across all subjects and objects within the boundary of an information system. Note the use of the word “policy” in the broad, English, sense.

It means that access control policy decisions are made by a central authority, not by the individual owner of an object. Users cannot change access rights.

What is Discretionary Access Control(DAC)?

By opposition, DAC leaves a certain amount of access control to the discretion of the object’s owner, or anyone else who is authorized to control the object’s access. The owner can determine who should have access rights to an object and what those rights should be.

Knowledge is power

While it may appear overwhelming at a first glance, organizing this alphabet soup into simple definitions is less scary than it seems and is crucial to understanding defenses against security risks. Knowing what each of these acronyms mean equips your team with the right tools to counter security breaches and other threats.

Want to take the power of knowledge a step further? Download our The State of Authorization: Playbook Edition to learn even more about:

• The different authorization models
• The differences between authentication and authorization
• How authorization can optimize existing IAM investments
• Considerations around Generative AI in authorization policy