Fine-Grained Authorization

Permissions that follow your objects

Share a document, inherit from a folder, block one user. Model relationships once, then ask one API who can do what to which object, and see why.

A model language you can read: Types, relations, and rules like viewer from parent, saved as versions.
Answers with proof: A check returns the path that granted access, not only yes or no.
Assertions before production: Save the checks that must keep passing and run them beside the model.
Scoped clients, seven-day logs: Each service gets only the access it needs, and every call is searchable.

Model

model
  schema 1.1

type user

type group
  relations
    define member: [user]

type folder
  relations
    define owner: [user]
    define viewer: [user, group#member] or owner

type doc
  relations
    define parent: [folder]
    define blocked: [user]
    define viewer: [user, user:*] or viewer from parent
    define can_read: viewer but not blocked

Check, with the proof

curl https://api.authdog.com/fga/v1/check \
  -H "Authorization: Bearer $AUTHDOG_ENV_API_SECRET" \
  -d '{
    "object": "doc:roadmap",
    "relation": "can_read",
    "subject": "user:angela",
    "trace": true
  }'

{ "allowed": true,
  "trace": {
    "label": "doc:roadmap#can_read",
    "children": [ "folder:eng#viewer",
                  "group:eng#member",
                  "Direct Users",
                  "user:angela" ] } }

Model

Describe who can do what, once

Write the model in an OpenFGA-style language. Authdog stores each save as a version with its own ID, and draws the model as a graph while you type.

A model language you can read

Types, relations and rules like viewer from parent. Combine rules with or, and, and but not. Allow a user, everyone, or a group's members per relation.

Typed subjects

Each relation says which subjects it accepts. A tuple with the wrong subject type is rejected on write, not discovered in production.

Immutable model versions

Every save keeps the one before it. Open an earlier version, pin a check to a model ID, or roll forward from an old one.

Live model graph

Types and relations as nodes, inheritance as dashed arrows. See an inheritance mistake before it ships.

Decide

Answer the question your app actually asks

One REST API for per-object checks, batches, and the lists a page needs. Authenticated with an environment API secret.

Check and BatchCheck

Can this user do this to this object? Ask one at a time or send a batch and match answers by correlation ID.

The proof, not just the answer

Add trace to a check and get the path that granted access: the group, the folder, the direct tuple. Debug access in minutes.

ListObjects and Expand

Which documents can Angela open? Who can open this one? Both answered from the same model.

Permissions Index

Early access. Precompute what each user can reach for chosen relations, so a list page needs one lookup instead of one check per row.

Build and test

A workspace, not a text file

The console module walks you from an empty store to a tested model, with the model, the data and the tests side by side.

Tuple Management

Add, edit and search relationship tuples, then ask the query tool whether a user is related to an object. A yes comes with the path.

Assertions in Developer Mode

Save the checks that must keep passing, run them all or one at a time, and see pass or fail beside the model you are editing.

Guided from the first step

Getting Started tracks what you have done: a saved model, a tuple, an assertion, a client. Short tours explain each view.

Everything over REST

Models, assertions, tuples and checks all have API routes, so the console is a view of the system and not the only way in.

Operate

Run it in production with the controls you expect

Know who called what, give each service only the access it needs, and keep environments apart.

Scoped clients

Create a client per service with check, read, write or model permissions. A check-only client cannot write a tuple. The secret is shown once.

Seven days of request logs

Search by operation, status, client or IP, with the request and response for each call.

One store per environment

Development, staging and production each have their own model, tuples and clients. Nothing crosses by accident.

Beside RBAC and ABAC

Pick the model the environment needs. Roles for coarse access, relationships when permissions inherit through objects.

Free trial

Request a free trial

Tell us what you're building and we'll get you set up with a trial, plus someone who can answer questions as you evaluate.

Full access to the platform while you evaluate it
Help wiring it into your stack from someone who knows it
Answers on SSO, SCIM, residency, and compliance requirements

Model

Describe your object types and relations, and save the first version.

Write

Add relationship tuples as users, groups and resources change.

Check

Ask the API before every protected action, and assert the cases that matter.

Model access the way your product shares things

Start with the console module, then call the API from your backend.

Start Building