Skip to main content

Fine-Grained Access (FGA)

Fine-Grained Access (FGA) is SecureAuth Connect's product capability for object-level authorization. FGA answers "who can do what on this specific resource" and is how you ship Relationship-Based Access Control (ReBAC) on SecureAuth.

ReBAC and FGA

ReBAC is the access control model. FGA is how SecureAuth ships it. ReBAC tells you what the decision shape looks like; FGA tells you how to configure, operate, and call it in production.

What FGA delivers​

FGA on SecureAuth is a Zanzibar-based implementation of ReBAC, delivered through Permission systems. You get:

  • A schema language to describe object types, relations, and permissions for your domain.
  • A relationship store to persist the specific relationships that exist in your system.
  • A check API to ask "can this subject perform this action on this object" at runtime.
  • Multi-system isolation so you can run multiple permission systems per tenant, for example one per identity pool or one dedicated to a single application.

Get started in three steps​

1. Define your authorization model​

Write the schema that describes the object types, relations, and permissions in your domain. For example, a document type has owner and viewer relations, and the owner relation grants the edit and read permissions.

2. Write your authorization data​

Populate the relationship store with the specific relationships that exist in your system: this user is the owner of that document, this team is a viewer of that folder, this folder contains that document.

3. Check permissions​

Call the SecureAuth permission check from your service. The system walks the graph to verify the path between the subject and the resource and returns the decision. Use the result to allow or deny the action.

For configuration detail, see Permission systems and Configuring permissions for application access control.

Where FGA fits​

FGA handles the questions that role attributes and context rules cannot answer cleanly:

  • RBAC answers "what can this role do." Good for coarse, function-based access.
  • PBAC and ABAC answer "do the request attributes satisfy this policy." Good for contextual and attribute-driven decisions.
  • FGA answers "who can do what on this specific resource." Good for object-level access at scale.

Most systems combine the three. FGA handles object-level access, RBAC handles coarse roles, and PBAC handles contextual overrides.

FGA and SecureAuth policies​

FGA runs alongside SecureAuth policies. A typical layered deployment:

  • A PBAC policy at the API gateway applies high-level rules (is the scope valid, is MFA present).
  • An FGA check inside the application confirms that this specific subject has a permission path to the specific object being touched.
  • An RBAC claim in the token gates coarse feature access.

See Choosing an access control model for the model-selection decision and Where authorization happens for the enforcement map.

See also​