---
title: "Microservices Authorization with OpenFGA"
description: "Centralize authorization across microservices with OpenFGA. One model, one store, one set of decisions — instead of a roles table per service."
canonical: "https://openfga.dev/docs/use-cases/microservices-authorization"
content_type: "documentation"
last_updated: "2026-09-04T10:33:45.000Z"
---

# Microservices Authorization

Microservices repeat the same pattern: each service ends up with its own roles table, its own permission checks, and its own subtle drift. OpenFGA centralizes that into a single authorization service that every microservice consults.

## The pattern

- **One OpenFGA store** holds the model and tuples for the whole system.
- **Each microservice** calls `check`, `list-objects`, or `list-users` over the OpenFGA API rather than implementing its own permission logic.
- **Writes go through the service that owns the relationship** (e.g. the membership service writes `member` tuples; the document service writes `can_share` tuples).

## Why this beats per-service authorization

- **One model to reason about.** Cross-service questions (_"can this user read this document via their team's project access?"_) become a single graph traversal instead of a coordination dance.
- **No more drifted roles tables.** A relation defined once in the OpenFGA model is the same relation in every service.
- **Reverse queries work across services.** `list-objects` returns every resource the user can access, regardless of which service owns it.

## Simplified model

```
type user



type team

  relations

    define member: [user]



type project

  relations

    define team: [team]

    define can_view: member from team

    define can_edit: member from team



type document

  relations

    define project: [project]

    define can_view: can_view from project

    define can_edit: can_edit from project
```

The membership service writes `team#member` tuples; the project service writes `project#team`; the document service writes `document#project`. Any service — including ones that only read documents — answers permission questions with a single `check` against the same OpenFGA store, instead of reimplementing team/project/document role logic locally.

## Operational shape

- **Latency.** Run OpenFGA close to the calling services. Sizing depends on workload, but production deployments routinely hit thousands of RPS at single-digit-to-low-double-digit ms p99 on PostgreSQL.
- **Caching.** OpenFGA supports check caching; pair with short cache TTLs in clients for hot paths.
- **Observability.** Treat authorization decisions as a first-class metric. Track check rate, latency, and authorization failures per service.

## Related reading

- [Running OpenFGA in production](https://openfga.dev/docs/best-practices/running-in-production.md)
- [Source of truth](https://openfga.dev/docs/best-practices/source-of-truth.md)
- [Multi-tenant SaaS](https://openfga.dev/docs/use-cases/multi-tenant-saas.md)