Skip to main content
In this guide you’ll see how to model preventing users from accessing objects using Auth0 FGA. For example, blocking users from accessing a document, even if it has been already shared with them.

Before you start

Before you start this guide, make sure you’re familiar with some Auth0 FGA Concepts and know how to develop the things listed below.

Step by step

With the above authorization model and relationship tuples, Auth0 Fine-Grained Authorization (FGA) will correctly respond with {"allowed":true} when check is called to see if Carl and Becky can edit this document. We can verify that by issuing two check requests: We want to share a document with the product team and also have the ability to deny certain users access, even if they have the document shared with them already. We can verify this by blocking Carl (who we have seen already has edit access) from editing the document. In order to do that, we need to:
  1. Modify our model to allow indicating that users can be blocked from accessing a document
  2. Modify our model to indicate that users who are blocked can no longer edit the document
  3. Verify that our solution works:
a. Indicate that Carl is blocked from the planning document b. Carl (now blocked) can no longer edit the document c. Becky still has edit access

01. Modify our model so users can be blocked from accessing a document

To allow users to be “blocked” from accessing a document, we first need to allow this relation. We’ll update our store model to add a blocked relation to the document type. The authorization model becomes this: Now we can add relationship tuples indicating that a certain user is blocked from editing a document.

02. Modify our model so users who are blocked can no longer edit the document

Now that we can mark users as blocked from editing documents, we need to support denying the editor relationship when a user is blocked. We do that by modifying the relation definition of editor, and making use of the exclusion operator to exclude the set of blocked users, as we can see here:

03. Verify our solution works

To check if our new model works, we’ll add a relationship tuple with Carl as blocked from document:planning and then verify that Carl no longer has editor access to that document.

a. Indicate that Carl is blocked from the planning document

With our modified authorization model, we can indicate that Carl is blocked by adding this relationship tuple.

b. Carl (now blocked) can no longer edit the document

We have modified the authorization model and added relationship tuples to indicate that Carl is blocked. Now let’s make sure our solution works as expected. To check if Carl still has access to the document, we can issue a check request with Carl as the user. The response is false, so our solution is working as expected.

c. Becky still has edit access

To check if Becky still has access to the document, we’ll issue another check request with Becky as the user. The response is true, indicating our model change did not inadvertently deny access for users who have access but are not blocked.
When creating tuples for Auth0 Fine-Grained Authorization (FGA) make sure to use unique ids for each object and user within your application domain. We are using first names and human-readable identifiers to make this task easier to read.