Concepts
The OpenFGA service answers authorization checks by determining whether a relationship exists between an object and a user. Checks reference your authorization model against your relationship tuples for authorization authority. Below are explanations of basic FGA concepts, like type and authorization model, and a playground to test your knowledge.
What Is A Type?
A type is a string. It defines a class of objects with similar characteristics.
The following are examples of types:
workspace
repository
organization
document
What Is A Type Definition?
A type definition defines all possible relations a user or another object can have in relation to this type.
Below is an example of a type definition:
- DSL
- JSON
type document
relations
define viewer: [user]
define commenter: [user]
define editor: [user]
define owner: [user]
{
"type": "document",
"relations": {
"viewer": {
"this": {}
},
"commenter": {
"this": {}
},
"editor": {
"this": {}
},
"owner": {
"this": {}
}
},
"metadata": {
"relations": {
"viewer": {
"directly_related_user_types": [
{
"type": "user"
}
]
},
"commenter": {
"directly_related_user_types": [
{
"type": "user"
}
]
},
"editor": {
"directly_related_user_types": [
{
"type": "user"
}
]
},
"owner": {
"directly_related_user_types": [
{
"type": "user"
}
]
}
}
}
}
What Is An Authorization Model?
An authorization model combines one or more type definitions. This is used to define the permission model of a system.
Below is an example of an authorization model:
- DSL
- JSON
model
schema 1.1
type document
relations
define viewer: [domain#member, user]
define commenter: [domain#member, user]
define editor: [domain#member, user]
define owner: [domain#member, user]
type domain
relations
define member: [user]
type user
{
"schema_version": "1.1",
"type_definitions": [
{
"type": "document",
"relations": {
"viewer": {
"this": {}
},
"commenter": {
"this": {}
},
"editor": {
"this": {}
},
"owner": {
"this": {}
}
},
"metadata": {
"relations": {
"viewer": {
"directly_related_user_types": [
{
"type": "domain",
"relation": "member"
},
{
"type": "user"
}
]
},
"commenter": {
"directly_related_user_types": [
{
"type": "domain",
"relation": "member"
},
{
"type": "user"
}
]
},
"editor": {
"directly_related_user_types": [
{
"type": "domain",
"relation": "member"
},
{
"type": "user"
}
]
},
"owner": {
"directly_related_user_types": [
{
"type": "domain",
"relation": "member"
},
{
"type": "user"
}
]
}
}
}
},
{
"type": "domain",
"relations": {
"member": {
"this": {}
}
},
"metadata": {
"relations": {
"member": {
"directly_related_user_types": [
{
"type": "user"
}
]
}
}
}
},
{
"type": "user"
}
]
}
Together with relationship tuples, the authorization model determines whether a relationship exists between a user and an object.
OpenFGA uses two different syntaxes to define the authorization model:
- A JSON syntax accepted by the OpenFGA API that closely follows the original syntax in the Zanzibar Paper. For more information, see Equivalent Zanzibar Concepts.
- A simpler-to-use DSL that's accepted by both the OpenFGA VS Code extension and OpenFGA CLI and offers syntax highlighting and validation in the VS Code extension. The DSL is used in the Sample Stores modeling examples and is translated to API-supported syntax using the CLI or OpenFGA language before being sent to the API.
Click here to learn more about the OpenFGA Configuration Language.
What Is A Store?
A store is an OpenFGA entity used to organize authorization check data.
Each store contains one or more versions of an authorization model and can contain various relationship tuples. Store data cannot be shared across stores; we recommended storing all data that may be related or affect your authorization result in a single store.
Separate stores can be created for separate authorization needs or isolated environments, e.g. development/prod.