---
sidebar_position: 9
slug: /modeling/token-claims-contextual-tuples
description: Using identity token claims to define contextual relations
---
import {
AuthzModelSnippetViewer,
CardBox,
CheckRequestViewer,
DocumentationNotice,
Playground,
ProductConcept,
ProductName,
ProductNameFormat,
RelatedSection,
RelationshipTuplesViewer,
UpdateProductNameInLinks,
WriteRequestViewer,
} from '@components/Docs';
# Use Token Claims As Contextual Tuples
Contextual Tuples allow authorization checks that depend on dynamic or contextual relationships that have not been written to the store, enabling some Attribute Based Access Control (ABAC) use cases.
To enable more ABAC use-cases that rely on specific attributes and conditions, you can also use `s [conditions](./conditions.mdx).
## Before You Start
To follow this guide, familiarize yourself with the following :
- A : is a string defined in the type definition of an authorization model that defines the possibility of a relationship between an object of the same type as the type definition and a user in the system.
- A : is a call to the check endpoint that returns whether the user has a certain relationship with an object.
- A : a grouping consisting of a user, a relation and an object stored in
## User Directories, Identity Tokens, And Relationships
User directories store user information that's accessed when making authorization decisions, like the group the user belongs to, their roles, or their department. The natural way to use those relationships in a Relationship-Based Access Control system like is to create tuples for each relation. However, implementing a synchronization mechanism to keep the user directory data up to date with tuples in the store can be challenging.
When applications implement authentication using an OIDC authorization service, they receive an ID Token or an Access token, with certain claims that can be customized based on the application's needs. Instead of writing tuples to the , you can use the content of the token in Contextual Tuples to make authorization checks, understanding that, if those relationships change while the token has not expired, users will still get access to the resources the content of the token entitled them to.
## Example
In this example, the application uses the following authorization model, in which documents can be viewed by members of a group:
When a group is added as a viewer of a document, the application writes tuples like those below:
Let's assume that the Access Token the application receives has a list of the groups the user belongs to:
```json
{
"iss": "https://id.company.com",
"sub": "6b0b14af-59dc-4ff3-a46f-ad351f428726",
"name": "John Doe",
"iat": 1516239022,
"exp": 1516239022,
"azp" : "yz54KAoW1KGFAUU982CEUqZgxGIdrpgg",
"groups": ["marketing", "everyone"]
}
```
When making a authorization check, the application uses the `groups` claim in the token and adds contextual tuple for each group, indicating that the user is a member of that group:
The authorization check returns `allowed = true`, as there's a stored tuple saying that members of the `marketing` group are viewers of the `product-launch` document, and there's a contextual tuple indicating that the user is a member of the `marketing` group.
:::caution Warning
Contextual tuples:
- Do not persist in the store.
- Are only supported on the , and . They are not supported on read, expand, or other endpoints.
- If you use the to build a permission aware search index, it may be difficult to account for contextual tuples.
:::
## Related Sections