Step 1

Capture the Person node whose external_id will match the JWT sub claim. The Capture pipeline is where the link between identity-provider claims and graph data is established - the external_id you choose here is the contract.

{
  "nodes": [
    {
      "external_id": "alice",
      "is_identity": true,
      "type": "Person",
      "properties": [
        {
          "type": "email",
          "value": "alice@email.com"
        },
        {
          "type": "given_name",
          "value": "Alice"
        },
        {
          "type": "last_name",
          "value": "Smith"
        }
      ]
    },
    {
      "external_id": "knightrider",
      "type": "Person",
      "is_identity": true,
      "properties": [
        {
          "type": "email",
          "value": "knightrider@demo.com"
        },
        {
          "type": "name",
          "value": "Michael Knight"
        }
      ]
    },
    {
      "external_id": "satchmo",
      "type": "Person",
      "is_identity": true,
      "properties": [
        {
          "type": "email",
          "value": "satchmo@demo.com"
        },
        {
          "type": "name",
          "value": "Louis Armstrong"
        }
      ]
    },
    {
      "external_id": "karel",
      "type": "Person",
      "is_identity": true,
      "properties": [
        {
          "type": "email",
          "value": "karel@demo.com"
        },
        {
          "type": "name",
          "value": "Karel Plihal"
        }
      ]
    },
    {
      "external_id": "kitt",
      "type": "Car",
      "is_identity": false,
      "properties": [
        {
          "type": "manufacturer",
          "value": "pontiac"
        },
        {
          "type": "model",
          "value": "Firebird"
        }
      ]
    },
    {
      "external_id": "cadillacv16",
      "type": "Car",
      "is_identity": false,
      "properties": [
        {
          "type": "manufacturer",
          "value": "Cadillac"
        },
        {
          "type": "model",
          "value": "V-16"
        }
      ]
    },
    {
      "external_id": "harmonika",
      "type": "Bus",
      "is_identity": false,
      "properties": [
        {
          "type": "manufacturer",
          "value": "Ikarus"
        },
        {
          "type": "model",
          "value": "280"
        }
      ]
    },
    {
      "external_id": "listek",
      "type": "Ticket",
      "is_identity": false
    },
    {
      "external_id": "airbook-xyz",
      "type": "Laptop",
      "is_identity": false
    }
  ]
}

Step 2 (input)

An OIDC access token your IdP issues to Alice after sign-in. Note that sub = "alice" and email = "alice@email.com" - both line up with the captured Person node above.

{
  "iss": "https://your-idp.example.com/",
  "sub": "alice",
  "email": "alice@email.com",
  "aud": [
    "client_id-of-your-app"
  ],
  "iat": 1749319876,
  "exp": 1749406276,
  "scope": "openid profile email"
}

Step 2

Token Introspect configuration. Two settings carry the entire identity contract:

- sub_claim = "sub": the JWT claim used as the Token node's external_id. Combined with the CIQ filter subject.external_id = $token.sub, this is what binds the bearer token to a specific Person node.

- claims_mapping: each entry copies a JWT claim onto the Token node as a property. Mapped claims also become available as $token.<claim> in CIQ filters, so you can author policies like subject.property.email = $token.email if you prefer to bind by a different field.

resource "indykite_token_introspect" "person_subject" {
  name         = "person-subject-introspect"
  display_name = "Person subject - introspect"
  description  = "Validates bearer tokens for Person subjects in CIQ queries."
  location     = "ProjectGID"

  jwt_matcher {
    issuer   = "https://your-idp.example.com/"
    audience = "client_id-of-your-app"
  }

  offline_validation {}

  # External-id-of-token-node is taken from the 'sub' claim by default.
  # Setting sub_claim explicitly is the most common way to bind a JWT to an
  # existing Person node: the value of this claim becomes the Token node's
  # external_id, and the policy filter (subject.external_id = $token.sub)
  # then resolves the subject to the matching Person.
  sub_claim = "sub"

  # claims_mapping copies token claims onto the Token node as properties.
  # Below, the 'email' claim becomes a property of type 'email' on the Token
  # node, which lets you cross-reference the authenticated identity in
  # Knowledge Queries (e.g., subject.property.email = $token.email).
  claims_mapping = {
    "email" = "email"
  }

  ikg_node_type  = "Token"
  perform_upsert = true
}

Step 3

CIQ Policy with the simplest possible Person subject:

- subject.type = Person.

- condition.cypher matches every Person and the filter narrows it to the one whose external_id equals $token.sub.

- allowed_reads exposes subject and two of its properties so the Knowledge Query can return them.

{
  "meta": {
    "policy_version": "1.0-ciq"
  },
  "subject": {
    "type": "Person"
  },
  "condition": {
    "cypher": "MATCH (subject:Person)",
    "filter": [
      {
        "operator": "=",
        "attribute": "subject.external_id",
        "value": "$token.sub"
      }
    ]
  },
  "allowed_reads": {
    "nodes": [
      "subject",
      "subject.property.email",
      "subject.property.name"
    ]
  }
}

Request to create the policy.

{
  "project_id": "your_project_gid",
  "description": "CIQ policy authorizing the Person subject whose external_id matches the bearer token's sub claim. The binding relies on Token Introspect resolving the JWT and exposing sub via $token.sub.",
  "display_name": "policy - person from token",
  "name": "policy-person-from-token",
  "policy": "{\"meta\":{\"policy_version\":\"1.0-ciq\"},\"subject\":{\"type\":\"Person\"},\"condition\":{\"cypher\":\"MATCH (subject:Person)\",\"filter\":[{\"operator\":\"=\",\"attribute\":\"subject.external_id\",\"value\":\"$token.sub\"}]},\"allowed_reads\":{\"nodes\":[\"subject\",\"subject.property.email\",\"subject.property.name\"]}}",
  "status": "ACTIVE",
  "tags": []
}

Step 4

Knowledge Query - returns the authenticated user's own external_id, email, and name. No input params: the policy already selects the subject from the token.

{
  "nodes": [
    "subject.external_id",
    "subject.property.email",
    "subject.property.name"
  ]
}

Request to create the Knowledge Query.

{
  "project_id": "your_project_gid",
  "description": "Return the authenticated Person's own profile. The subject is selected by matching subject.external_id against $token.sub (resolved by Token Introspect).",
  "display_name": "knowledge query - my profile",
  "name": "kq-my-profile",
  "policy_id": "your_policy_gid",
  "query": "{\"nodes\":[\"subject.external_id\",\"subject.property.email\",\"subject.property.name\"]}",
  "status": "ACTIVE"
}

Step 5

Execute the query as Alice. Authentication = AppAgent credential in X-IK-ClientKey + Alice's bearer token in Authorization: Bearer <token>. input_params is empty because the identity binding comes from the JWT.

{
  "id": "your_query_gid_or_name",
  "input_params": {}
}

Response - exactly Alice's record. Sending the same request with Bob's bearer token would return Bob's record instead. The query body is unchanged; the token decides.

{
  "data": [
    {
      "nodes": {
        "subject.external_id": "alice",
        "subject.property.email": "alice@email.com",
        "subject.property.name": "Alice Smith"
      }
    }
  ]
}