Authzed Terminology is currently a work-in-progress and is open to public feedback. If anything is confusing or you find something inconsistent, we'd love to hear from you.
Submitting feedback is as simple as typing anything into the box below and clicking the submit button:
A grouping of permissions systems under one payer account and administrator team.
The self-contained combination of a
The list of possible
Object Type definitions and their implied/computed
Type A class of objects that can exist in Authzed that all contain the same
The unique identifier (e.g. uuid, database row ID, JWT sub claim) which is used to refer to a single instance of an
The combination of
Object Type and object ID which refers to a unique entity that exists outside of Authzed, e.g. "The user Aleksander" or the "The engineering team".
Object Reference when used as the subject of a
Relationship, with an optional relation.
One possible way, defined in the
Schema, that one object type can relate to another, e.g. Teams can have
members are of object type
The specific way in which an
Object Reference and
Subject Reference relate to one another, e.g. Brenna (
Subject) is a member (
Relation) of the engineering team (
One possible access type that can be requested and computed by Authzed, e.g.
A handle that can be used to grant access to one or more
Permissions Systems with various levels of access.
A secret access token that is used to authenticate a request on behalf of an
An opaque value which when given back to Authzed, carries extra information about the entity in question to allow for faster correct permissions decisions.
For those who are familiar with the Zanzibar paper, the following table explains how Authzed terms map to Zanzibar terms:
|Zanzibar Term||Authzed Term|
|Tupleset Filter||Relationship Filter|