Fine-grained Authorization

Fine grained controls to manage access to your resources using attributes and advanced rules

What is Fine Grained Authorization (FGA)?

Fine-grained authorization determines users' access rights to infrastructure, data, or resources. Unlike coarse-grained access control (CGAC), which relies on a single factor, such as role, to grant access, FGA bridges multiple factors and provides fine access to resources. For example, it may consider policies (policy-based access control) attributes (attribute-based access control), or a combination of multiple 'screening' options to provide access only to the relevant persona(s).

Frontegg's Finely Grained Authorization allows you to manage granular access control to your resources using attributes and advanced rules. This mechanism lets you control user collaboration in your applications with a quick setup that syncs your OPA agent with your cloud. Before jumping into the concept of FGA and Attribute-based access control, It's important to understand some core concepts.


There are multiple ways to enable user access control, and finely-grained authorization covers multiple approaches to facilitate very granular user access. The main ones are Role-based Access Control (RBAC), Relationship-based Access Control (ReBAC), and Attribute-based Access Control (ABAC).

Role-based access control (RBAC) is an approach to data security that permits or restricts system access based on a role a user has. This dictates the access that is part of Permissions, a subset of user Roles.

Relationship-based access control (ReBAC)

Another refinement of access control is Relationship-Based Access Control(ReBAC). To understand the concept of ReBAC, let's look at a hierarchical structure where permissions need to be limited to the level of files and folders. We can define different object types like user, folder, and document. We can also define the relationship users inherit based on their roles – e.g., owner, editor, and viewer, as well as a parent-child relationship between documents and folders. Finally, we can define permissions given as part of every role. For example, we can say that users with a viewer role are granted a read permission when viewing documents, and editors and owners of folders are granted write permission in addition to read permissions. The parent is a special relationship that indicates what its sub-folders will inherit. This way, we can define permissions in a very finely-grained way and have them flow down the hierarchy.

What is Attribute-Based Access Control (ABAC)

Attribute-based access control (ABAC) is an approach to data security that permits or restricts data access based on assigned user, object, action, and environmental attributes. In contrast to Role-based access control - which relies on Permissions derived from a user's Role - ABAC has multiple dimensions that grant users access control. This makes attribute-based access control a highly dynamic model because policies, users, and objects can be provisioned independently, and policies make access control decisions when the data is requested (more about Policies below).

Attributes extend beyond roles and relationships, encapsulating concepts such as the ability for anyone to read a repository marked as public. In this case, the public attribute exemplifies an attribute that isn't inherently a relationship.

Even though relationship models may not encompass all ABAC use cases, they effectively address a significant portion of interesting scenarios. Exploring these models provides valuable insights into their applicability.

Here's a short explanation of the elements of attribute-based access control. You can see how this allows better granularity and flexibility in segmenting access.

Attribute: A characteristic of any piece of data in the system. ABAC makes access decisions based on attributes of users, objects, actions, and environment.
User attributes: Information linked to the user's data— including name, title, department, and permission level.
Object attributes: Information linked to the data itself— including creator, type, creation date, and level of sensitivity.
Action attributes: Information about actions performed on a subject, including reading, editing, approving, and deleting.
Environmental attributes: Contextual information about the data, including location, access date, and organizational threat level.
Policy: A set of rules stating permission or restriction to data based on its attributes.

Attribute-based access control allows finely-grained authorization and covers both Roles and Relationship-based access control.

Now that you understand the basics of FGA and attribute-based access control, Let's jump into creating Your first FGA application.