> ## Documentation Index
> Fetch the complete documentation index at: https://openfga.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# What is Fine-Grained Authorization?

> Fine-grained authorization decides access at the resource and action level. Learn what FGA is, what it buys you, and how OpenFGA implements it.

**Fine-grained authorization (FGA)** means deciding access at the level of the individual resource and action, rather than at the role or coarse-scope level. *"Alice can edit document-42"* is fine-grained; *"Alice is an editor"* is not.

<h2 id="what-fine-grained-actually-buys-you">What "fine-grained" actually buys you</h2>

* **Per-resource sharing.** A user can be granted access to one document without inheriting access to everything in the workspace.
* **Hierarchical inheritance.** Access to a folder grants access to its documents — but only that folder, not every folder.
* **Reverse queries.** *"List every document this user can read"* — the query a UI needs to render correctly.
* **Cross-tenant collaboration.** Granting a single resource to an external user without making them a tenant member.

Coarse-grained models can simulate these with enough effort, but the authorization layer ends up duplicating a graph database in roles tables. Fine-grained engines store the graph directly.

<h2 id="how--implements-fga">How OpenFGA implements FGA</h2>

* A typed [model](/docs/configuration-language) defines resource types and the relations between them.
* [Tuples](/docs/concepts) record specific relationships between specific principals and specific resources.
* The [check API](/docs/interacting/relationship-queries) answers per-action questions in milliseconds.
* [Conditions](/docs/modeling/conditions) cover attribute-driven cases inside the same model.

## Where FGA matters most

* **Document management and collaboration** (Google Drive, Notion, Figma patterns).
* **Multi-tenant SaaS** with external sharing.
* **AI agents and RAG**, where each user must only see their slice of the corpus — covered in [AI agent authorization](/docs/use-cases/ai-agent-authorization).

## Choosing the right model

A short decision path:

* **Flat access, a handful of roles, single tenant** — [RBAC](/docs/learn/rbac-vs-rebac) is enough.
* **Decisions driven mostly by request attributes** (region, department, time-of-day) — start with [ABAC](/docs/learn/abac-vs-rebac) or a [policy engine](/docs/learn/policy-engine).
* **Hierarchy, sharing, multi-tenancy, or reverse queries** — you want a relationship engine. OpenFGA handles attribute checks too via [conditions](/docs/modeling/conditions), so you usually don't need a second engine.
* **Mixed infrastructure + application policy** — a policy engine at the admission layer plus OpenFGA for the application is the common pairing.

## Related reading

Learn more about OpenFGA.

<CardGroup>
  <Card title="Authorization Concepts" href="/docs/authorization-concepts">
    Core authorization terminology.
  </Card>

  <Card title="ReBAC overview" href="/docs/learn/rebac">
    Relationship-Based Access Control explained.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.