Fine-Grained Authorization (FGA)

WorkOS Fine-Grained Authorization (FGA) is a centralized authorization service for customer applications. Teams can use FGA to implement a custom authorization model tailor-made for their application(s), with the ability to integrate elements of role-based access control (RBAC), relationship-based access control (ReBAC), and attribute-based access control (ABAC) as needed.

One of the most common forms of access control, role-based access control involves 3 main entities: roles, permissions and users. Permissions define behaviors that are grouped together into roles (e.g. admin, owner). Roles are then assigned to users to grant them the ability to perform a group of behaviors. RBAC is common within B2B software and SaaS applications used by enterprises, often being necessary to meet regulatory, compliance, and/or enterprise contract requirements.

Most applications start by implementing RBAC with a static set of roles. This works well for simple applications used by one customer (single-tenant). However, this model often breaks down in multi-tenant applications (apps used by multiple customers). Different customers might require a different set of roles or a different mapping of roles to permissions. This requirement introduces a new dimension (tenant) on top of existing roles, permissions, and users, requiring a flexible access model to prevent a problem known as role explosion.

Fine-grained access control is a more granular form of access control that is becoming popular in applications today. As opposed to the coarse-grained access control provided by RBAC, which grants access to behaviors across all resources, FGAC allows applications to grant users certain behaviors per resource.

For example, while a RBAC rule might specify that [admins] can [edit] [reports], a fine grained rule can specify that [user:1] can [edit] [report:xsd34].

FGAC can also be used in conjunction with RBAC to enable what we call ‘fine-grained RBAC’. This is especially common in SaaS apps and developer tools. For example, let’s take a cloud infrastructure multi-tenant SaaS that defines a resource called customer-application. A ‘customer-application’ can have owners, editors and viewers. Now let’s say that the users within this SaaS can have multiple ‘roles’ within their ‘tenant’ based on their access level. In order to specify an access rule like all [admins] of [tenant:x] can [edit] [all applications] that belong to [tenant:x], we need ‘fine-grained RBAC’, or the ability to specify resource-level rules by role.

One of the most common use cases for FGAC is to enable access control on user-generated content, similar to Google Docs or Box. With FGAC, you can easily define owners, editors and viewers of your own resources and objects (ex. documents, reports).

Another common use case for FGAC is to model complex organization hierarchies, often those found within most mid-large scale enterprises. For example, let’s say that we’d like to specify a rule within an organization which states that all [members] of [team:x] can access [report:y87dXfd]. Furthermore, let’s say that membership in team:x is driven by org hierarchy and whether a specific person reports to a given manager.

Using a FGA system, we can model the exact org hierarchy as well as easily define rules such as all [direct reports] of [manager:y] are [members] of [team:x] and all [members] of [team:x] can access [report:y87dXfd] in order to process queries such as can [user:1] access [report:y87dXfd] in realtime.

Similar to enterprise org hierarchies, apps with complex regional hierarchies are a good use case for FGAC. For example, let’s say we’re building a supply-chain or operations-focused SaaS app where data and functionality is separated by region. We may have region:east and region:west to distinguish the two core regions with teams and users defined within each region.

Using a FGA system, we can accurately model the regions and easily make queries against it at runtime to ensure that the right users have access to the right data and functionality.

Although not directly related to security, a common form of access control often used within SaaS is what we call ‘pricing tiers & feature entitlements’. Pricing tiers are groups of features within an app, typically assigned based on the end customer’s payment tier. Mature SaaS apps often build out their own management and enforcement layer for pricing tiers, in order to support everything from feature overrides and metering to integrations with payment systems.

With a FGAC system, pricing tiers and feature entitlements can be expressed as rules like [company:x] is on [tier:enterprise] and [feature:dashboard] is part of [tier:enterprise] in order to easily support runtime queries like can [user:y] which is a member of [company:x] access [feature:dashboard]?