Blocklists

Blocklist users from accessing certain resources based on specific attributes or warrants

This guide is now available as an example in the FGA Playground, where you can interact with the schema, warrants, and queries in real-time!

A blocklist allows systems to deny access to specific users or sessions based on contextual data or warrants.

When to Use It?

A user IP address is associated with suspicious behavior

A user is flagged for abuse

A user is subject to temporary access restrictions (e.g., after multiple failed login attempts)

This approach combines relationship-based access control (ReBAC) with attribute-based access control (ABAC), giving you fine-grained control without complicating your core permissions model.

Example Applications

Content Moderation: Block users from viewing or interacting with content based on their IP address.

E-commerce Systems: Block users from purchasing or viewing products based on behavior patterns.

Banking and Finance: Deny access based on fraud scores or geolocation mismatches.

Schema

 version 0.3

type user

type store
  relation member [user]

type item
  relation owner [store]
  relation blocked [user]

  relation view []
  inherit view if
    all_of
      relation member on owner [store]
      // Users are blocked either explicitly or with the ip_not_allowed policy
      none_of
        relation blocked
        policy ip_not_allowed


policy ip_not_allowed(ip_risk_score integer) {
  ip_risk_score > 75
}

Example

1. Apply the schema

Create a file called schema.txt containing the schema definition from above. Then use the CLI to apply this schema to your WorkOS FGA environment.

Note: make sure to select the correct environment with the CLI

 workos fga schema apply schema.txt

2. Create warrants

Create warrants that associate users, stores, and items. Add a blocked user to an item.

Create warrants

 curl "https://api.workos.com/fga/v1/warrants" \
  -X POST \
  -H "Authorization: Bearer sk_example_123456789" \
  --data-raw \
  '[
    {
      "op": "create",
      "resource_type": "store",
      "resource_id": "store-1",
      "relation": "member",
      "subject": {
        "resource_type": "user",
        "resource_id": "user_2oDscjroNWtzxzYEnEzT9P7VYEe"
      }
    },
    {
      "op": "create",
      "resource_type": "item",
      "resource_id": "item-1",
      "relation": "owner",
      "subject": {
        "resource_type": "store",
        "resource_id": "store-1"
      }
    },
    {
      "op": "create",
      "resource_type": "store",
      "resource_id": "store-1",
      "relation": "member",
      "subject": {
        "resource_type": "user",
        "resource_id": "user_3kLwpXyzQTuvbNApRmC5X4ZhAmd"
      }
    },
    {
      "op": "create",
      "resource_type": "item",
      "resource_id": "item-1",
      "relation": "blocked",
      "subject": {
        "resource_type": "user",
        "resource_id": "user_3kLwpXyzQTuvbNApRmC5X4ZhAmd"
      }
    }
  ]'

3. Check access

With our environment setup, we can check the user’s permission to view items.

Check if a user can view an item

 curl "https://api.workos.com/fga/v1/check" \
  -X POST \
  -H "Authorization: Bearer sk_example_123456789" \
  --data-raw \
  '{
    "checks": [
      {
        "resource_type": "item",
        "resource_id": "item-1",
        "relation": "view",
        "subject": {
          "resource_type": "user",
          "resource_id": "user_2oDscjroNWtzxzYEnEzT9P7VYEe"
        },
        "context": {
          "ip_risk_score": 90
        }
      },
      {
        "resource_type": "item",
        "resource_id": "item-1",
        "relation": "view",
        "subject": {
          "resource_type": "user",
          "resource_id": "user_3kLwpXyzQTuvbNApRmC5X4ZhAmd"
        },
        "context": {
          "ip_risk_score": 50
        }
      }
    ]
  }'