Check user authorization
The Check API returns whether a given user has a relationship with a given object in a given store.
The user field of the request can be a specific target, such as user:anne, or a userset (set of users) such as group:marketing#member or a type-bound public access user:*.
To arrive at a result, the API uses:
-
Explicit tuples written through the Write API
-
Contextual tuples present in the request
-
Implicit tuples that exist by virtue of applying set theory
For example: document:2021-budget#viewer@document:2021-budget#viewer. In this example, the set of users who are viewers of document:2021-budget are the set of users who are the viewers of document:2021-budget.
A contextual_tuples object may also be included in the body of the request. This object contains one field tuple_keys, which is an array of tuple keys. Each of these tuples may have an associated condition.
You may also provide an authorization_model_id in the body. This is used to assert that the input tuple_key is valid for the model specified. If not specified, the assertion is made against the latest authorization model ID.
Note: We recommend you specify authorization model id for better performance.
You may also provide a context object that is used to evaluate the conditioned tuples in the system.
Note: We recommend you provide a value for all the input parameters of all the conditions, to ensure that all tuples be evaluated correctly.
By default, the Check API caches results for a short time to optimize performance. You may specify a value of HIGHER_CONSISTENCY for the optional consistency parameter in the body to inform the server that higher conisistency is preferred at the expense of increased latency. Consideration should be given to the increased latency if requesting higher consistency.
The response returns whether the relationship exists in the field allowed.
Some exceptions apply, but in general, if a Check API responds with {allowed: true}, then you can expect the equivalent ListObjects query to return the object, and viceversa.
For example, if Check(user:anne, reader, document:2021-budget) responds with {allowed: true}, then ListObjects(user:anne, reader, document) may include document:2021-budget in the response.
Examples
Querying with contextual tuples
In order to check if user user:anne of type user has a reader relationship with object document:2021-budget given the following contextual tuple:
{
"user": "user:anne",
"relation": "member",
"object": "time_slot:office_hours"
}
the Check API can be used with the following request body:
{
"tuple_key": {
"user": "user:anne",
"relation": "reader",
"object": "document:2021-budget"
},
"contextual_tuples": {
"tuple_keys": [
{
"user": "user:anne",
"relation": "member",
"object": "time_slot:office_hours"
}
]
},
"authorization_model_id": "01G50QVV17PECNVAHX1GG4Y5NC"
}
Querying usersets
Some Checks always return true, even without any tuples. For example, for the following authorization model:
model
schema 1.1
type user
type document
relations
define reader: [user]
the following query:
{
"tuple_key": {
"user": "document:2021-budget#reader",
"relation": "reader",
"object": "document:2021-budget"
}
}
always returns { "allowed": true }. This is because usersets are self-defining: the userset document:2021-budget#reader always has the reader relation with document:2021-budget.
Querying usersets with difference in the model
A Check for a userset can yield results that must be treated carefully if the model involves difference. For example, for the following authorization model:
model
schema 1.1
type user
type group
relations
define member: [user]
type document
relations
define blocked: [user]
define reader: [group#member] but not blocked
the following query:
{
"tuple_key": {
"user": "group:finance#member",
"relation": "reader",
"object": "document:2021-budget"
},
"contextual_tuples": {
"tuple_keys": [
{
"user": "user:anne",
"relation": "member",
"object": "group:finance"
},
{
"user": "group:finance#member",
"relation": "reader",
"object": "document:2021-budget"
},
{
"user": "user:anne",
"relation": "blocked",
"object": "document:2021-budget"
}
]
},
}
returns { "allowed": true }, even though a specific user of the userset group:finance#member does not have the reader relationship with the given object.
Requesting higher consistency
By default, the Check API caches results for a short time to optimize performance. You may request higher consistency to inform the server that higher consistency should be preferred at the expense of increased latency. Care should be taken when requesting higher consistency due to the increased latency.
{
"tuple_key": {
"user": "group:finance#member",
"relation": "reader",
"object": "document:2021-budget"
},
"consistency": "HIGHER_CONSISTENCY"
}
Path Parameters
Body
"01G5JAVJ41T49E9TT3SKVS7X1J"
Controls the consistency preference for this request. Default value is UNSPECIFIED, which has the same behavior as MINIMIZE_LATENCY.
UNSPECIFIED, MINIMIZE_LATENCY, HIGHER_CONSISTENCY "MINIMIZE_LATENCY"
Additional request context that is used to evaluate any ABAC conditions encountered in the query evaluation.