Blog

What is Attribute Based Access Control (ABAC)?

Attribute-Based Access Control (ABAC) provides a targeted, more precise way to manage who can see and use different resources and under which conditions.


Broader access controls increase the risk of data leaks, privacy violations, property theft, or unintentional data manipulation.

In contrast, Attribute-Based Access Control (ABAC) provides a targeted, more precise way to manage who can see and use different resources and under which conditions. This focused approach greatly reduces the chances of unauthorized access.

In this article, we’ll explain what ABAC is exactly, explore situations where it’s particularly useful, its downsides, and discuss how to implement it.

What is ABAC?

Attribute-based access control (ABAC) is a granular, fine-grained form of authorization and access control. Unlike traditional models that rely strictly on roles or predefined rules, ABAC considers multiple characteristics, or "attributes," associated with users, the resources they want to access, the actions they wish to perform, and the context of their requests. 

A user's attributes could include their role, location, and the current time, while a resource's attributes might be its classification level and owner. ABAC allows for the definition of access policies based on these attributes.

The simplest ABAC policies are boolean in nature (e.g., the user either has an attribute or not), but more complex policies use multiple system and environment attributes like geo/location and time — as well as more complex logic like regex matching — to create more sophisticated policies.

One example of an ABAC policy is "all users with a @workos.dev email address can access report:x". This policy is based on a user's 'email' attribute and relies on regex matching to evaluate. It's a relatively simple but powerful policy with many real-world applications.

Examples of ABAC

Here are a few real-world examples showing how ABAC can be applied in different scenarios:

  • In a healthcare app, a doctor can access a patient's medical record if they are currently treating that patient or if it's an emergency and they are within hospital premises.
  • A bank employee can approve transactions over $10,000 only if they are a manager and they are accessing the system from a secure bank location during business hours.
  • Teachers can access students' exam results only for courses they teach, and if the academic term is currently in session.
  • Employees can access confidential documents only if they are from the intended department, using a company-issued device connected to the corporate network.

When should you use ABAC?

Below are some scenarios when you should use ABAC:

In complex and dynamic environments 

ABAC is ideal for environments where access requirements are not only complex but frequently change. Think about healthcare, finance, or government sectors — areas where who can see what might depend on different things, like a user’s job, the sensitivity of the information, or even where and when they’re trying to access it.

In highly regulated industries

In sectors such as healthcare and finance, regulations often dictate strict access controls. ABAC excels here because it can take into account a wide range of attributes — including compliance-related attributes like data sensitivity and user clearance — making it possible to enforce these complex rules consistently and effectively.

If users have diverse roles and responsibilities

Apps where users have varied roles that intersect with many different types of sensitive data will benefit from ABAC. 

For example, in a large hospital, staff roles can range from doctors and nurses to administrative and support staff, each requiring access to different levels of patient data under different conditions.

If you need fine-grained access control

When you need precise control over access, ABAC lets you set up nuanced policies that use multiple attributes to determine access rights. This is useful in scenarios where access needs to be tightly controlled and specifically tailored, such as in intellectual property companies or research institutions where data sensitivity can vary greatly.

If you want a scalable and flexible access management

As organizations expand, their access control requirements naturally become more complex due to a larger user base, more diverse roles, and an expanded range of resources that need protection. ABAC is flexible enough to handle this growth smoothly. It keeps up with the increasing number of users, roles, and resources without overly complicating the administrative process.

ABAC vs. RBAC

Role-Based Access Control (RBAC) is one of the most common methods for access control. It restricts system access based on a person's role within an organization.

Compared to ABAC, RBAC is easier to set up and manage because users are grouped by role, and resources are accessed based on those roles. If a role changes, adjustments to the access rights are made in just one place: the roles themselves.

However, because RBAC assigns permissions based on fixed roles, it can be limiting when you need to frequently update or fine-tune access rights for different users or when the number of roles starts to grow significantly. 

In such cases, it may require continually creating new roles or adjusting existing ones to cover all the possible combinations for different users. It also becomes difficult to ensure that access rights accurately reflect each user’s current responsibilities and access needs.

Use RBAC when:

  • You have a stable and clear structure with well-defined roles.
  • Access needs are relatively static and do not require frequent changes.
  • The environment is less dynamic, and role changes are minimal.

If possible, it's often better to use ABAC over other, more coarse-grained forms of access control, such as role-based access control (RBAC). 

The downsides of ABAC

Building an authorization system that supports ABAC comes with its own set of challenges. Here are a few to keep in mind:

Implementation complexity

ABAC systems, especially the components that handle policy resolution, are complicated to implement. They have to account for user/subject, environment, and object attributes, then resolve the complicated, nested policies that might exist between these attributes.

Keeping policies in sync with the data model

As is the case with other fine-grained authorization models like ReBAC (Relationship Based Access Control), one of the challenges with ABAC is keeping policies in sync with changes to the underlying data. 

For example, let's say that we have policies based on 3 user attributes: Email, username, and tenant. If any of these attributes change (i.e., a user moves tenants or is granted access to another tenant), the related ABAC policies will also need to be created, updated, or deleted. 

In other words, a small change in the data model can lead to multiple, cascading changes to your ABAC policies. As a result, ABAC systems often need to handle synchronization, including how to deal with failures and retries, all of which further increase complexity.

Managing environment attributes

One powerful aspect of ABAC systems is the ability to reference environment attributes in policies. 

For example, let's say that you want to define a time-based policy that specifies that "user:A can only access report:x between the hours of 9a and 5p". Implementing such a policy requires our ABAC system to understand and keep time such that it can be checked at runtime during a user query. 

Similarly, you might want to define policies based on user location or IP, which will require our ABAC system to resolve location. Neither of these is particularly easy to implement and represents custom logic that you'll need to build into the system.

Policy proliferation

As organizations grow and change, the number of policies can proliferate rapidly to address new access scenarios and requirements. With this increase, there's a higher risk of conflicts between them. 

Two or more policies might contradict each other, leading to ambiguity in access decisions. Some areas can also be either overregulated with overly restrictive access or under regulated with insufficient controls. Finding the right balance becomes harder as the number of policies grows, potentially leaving gaps that could be exploited.

Having more policies also ramps up the amount of upkeep needed. Regularly reviewing and updating a large set of policies is crucial to keeping them relevant and effective with any changes in the organization. This process can be quite resource-intensive.

Implementing ABAC

As mentioned above, implementing an ABAC system from scratch is not easy. There are multiple parts of the system to consider, including the resolution engine, policy synchronization, and how to manage and check environment attributes (time, geo/location, etc.). 

Each of these components can take a lot of engineering hours to implement and properly secure. It’s also costly to continuously monitor and update your system. 

There are open-source libraries that can simplify the process, but you’ll still have to configure and customize these libraries to work for your use case.

Fully managed and hosted ABAC solutions are much faster than starting from scratch. They offer:

  • Pre-built functionality: These solutions come with ready-to-use components, including user-friendly interfaces for policy management and built-in reporting tools.
  • Professional support: Assistance is available for troubleshooting, during initial integrations, and whenever issues arise.
  • Tested scalability: Commercial solutions are engineered to scale easily, supporting a growing number of users without performance degradation.
  • Built-in compliance: Many systems include compliance features for standards like GDPR, HIPAA, or PCI DSS, lightening the load on your compliance teams.

The bottom line

ABAC allows you to manage access control securely in dynamic and complex environments. WorkOS FGA  is one such service that offers ABAC-like policy support as part of its core, distributed AuthZ offering:

  • Get started quickly: Jump right in with WorkOS’s straightforward APIs and user-friendly SDKs.
  • Intuitive management dashboard: WorkOS’s dashboard is designed for ease of use for both technical and non-technical users. Manage policies and entitlements effortlessly, without a single line of code. 
  • Comprehensive audit logs: Stay on top of your security with real-time audit logs. Every change to policies, every policy evaluation, and its results are tracked and logged.
In this article

This site uses cookies to improve your experience. Please accept the use of cookies on this site. You can review our cookie policy here and our privacy policy here. If you choose to refuse, functionality of this site will be limited.