Fine-Grained Authorization (FGA / ReBAC)

Roles answer "what can this type of user do?" FGA answers "can this user do this to that specific object?" nexusID provides a relationship-based access control (ReBAC) model for per-object decisions alongside coarse-grained roles.

Admin console: /admin/fga

Concepts

• Authorization model — a versioned definition of object types and the relations between them (e.g. document has owner, editor, viewer).
• Relationship tuple — a fact like user:alice is editor of document:42.
• Check — a runtime query: "does user:alice have viewer on document:42?", answered by walking the relationship graph (direct + inherited).

How it works

You author a model and write relationship tuples as your application creates objects and shares. At request time the app calls a check; the engine evaluates direct and derived relationships and returns allow/deny. Models are versioned and auditable. Malformed-model or no-active-model errors are returned as HTTP 400 Bad Request.

Typical workflow

1. /admin/fga → define/activate an authorization model (object types + relations).
2. Write relationship tuples as objects are created/shared.
3. Call the check API from your app to authorize per-object actions.

Related

• Role Hierarchy — coarse-grained RBAC that FGA complements.
• Agentic Governance — scope what agents may touch per object.