Authorization

Authorization in Qeet ID is RBAC-first with a single-call check, group-level roles, an explainable mode that returns the grant-path trace, and an ABAC policy layer for rules RBAC can't express.

Permissions & roles

A permission is a string like billing:write. A role bundles permissions and is assigned to a user or a group within a tenant. A user's effective permissions are direct ∪ group-derived.

Assigning roles

To a user:

To a group (every member inherits the role's permissions):

Inspect a user's combined effective permissions in a tenant:

The check — single call

The hot-path question "may this principal do X?" is one request:

curl "https://api.qeetid.com/v1/check?user_id=$U&tenant_id=$T&permission=billing:write" \
  -H "Authorization: ApiKey $QEETID_API_KEY"
# → { "allowed": true }

const ok = await qeetid.can({ user: userId, tenant: tenantId, permission: "billing:write" });
// canAll(user, tenant, ["a", "b"]) → true only if all pass

ok, _ := qeetid.Can(ctx, qeetidsdk.PermissionCheck{User: userID, Tenant: tenantID, Permission: "billing:write"})

ok = qeetid.can(user=user_id, tenant=tenant_id, permission="billing:write")

Group-level roles

Assigning a role to a group grants it to every member transitively — the basis for directory-driven access. SCIM keeps group membership in sync (see Enterprise → SCIM), so adding someone to a group in Okta/Entra grants their roles in Qeet ID automatically.

Explainable authz

Add ?explain=true to /check and instead of the bare { allowed }, Qeet ID returns the full grant-path trace: every distinct grant (direct and group-derived) that confers the permission, or — on a denial — the reason. Most CIAM platforms can't tell you why a decision was made; Qeet ID can.

curl "https://api.qeetid.com/v1/check?user_id=$U&tenant_id=$T&permission=billing:write&explain=true" \
  -H "Authorization: ApiKey $QEETID_API_KEY"

{
  "allowed": true,
  "paths": [
    {
      "permission": "billing:write",
      "granted_by": "role:billing-admin",
      "via": "group:finance-team",
      "group_id": "…",
      "role_id": "…"
    }
  ]
}

{
  "allowed": false,
  "paths": [],
  "reason": "no role grants billing:write for this user in this tenant"
}

ABAC policy

For rules RBAC can't express (e.g. attribute matching), each tenant has an ABAC policy evaluated alongside RBAC. A request must satisfy both the required permission and any matching policy.