Authorization (Policy Check)

Runtime policy checking endpoints for authorization decisions. These endpoints evaluate whether a user has the required permissions for a given action by querying role bindings, roles, role permissions, and permissions.

How Policy Check Works

The authorization flow follows this chain:

role_bindings → roles → role_permissions → permissions

Scope matching: A binding matches if it has the specific scope requested OR is tenant-wide (NULL scope).

Admin Policy Check

Perform authorization checks against the primary admin database.

Endpoint: POST /uflow/admin/policy/check

Headers

Header	Type	Required	Description
Authorization	string	Yes	Bearer JWT token

Request Body

{
  "user_id": "string",
  "resource": "string",
  "action": "string",
  "scope_type": "string",
  "scope_id": "string"
}

Parameters

Parameter	Type	Required	Description
user_id	string	Yes	User to check authorization for
resource	string	Yes	Resource being accessed
action	string	Yes	Action being performed
scope_type	string	No	Scope type (null for tenant-wide)
scope_id	string	No	Scope ID (null for tenant-wide)

Response

Success (200):

{
  "allowed": true,
  "user_id": "string",
  "resource": "string",
  "action": "string",
  "matched_roles": ["string"]
}

Response Fields

Field	Type	Description
allowed	boolean	Whether the action is permitted
user_id	string	User ID checked
resource	string	Resource checked
action	string	Action checked
matched_roles	array	Roles that grant this permission

Error Responses:

• 400 - Bad Request - invalid input
• 500 - Internal Server Error

---

End-User Policy Check

Perform authorization checks against the tenant database. Tenant context is derived from the JWT token.

Endpoint: POST /uflow/user/rbac/policy/check

Headers

Header	Type	Required	Description
Authorization	string	Yes	Bearer JWT token

Request Body

{
  "user_id": "string",
  "resource": "string",
  "action": "string",
  "scope_type": "string",
  "scope_id": "string"
}

Response

Success (200):

{
  "allowed": true,
  "user_id": "string",
  "resource": "string",
  "action": "string",
  "matched_roles": ["string"]
}

Error Responses:

• 400 - Bad Request
• 401 - Unauthorized
• 500 - Internal Server Error

---

Usage Examples

Check if a user can read billing data

curl -X POST https://dev.api.authsec.dev/uflow/admin/policy/check \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "user-uuid",
    "resource": "billing",
    "action": "read"
  }'

Check scoped permission

curl -X POST https://dev.api.authsec.dev/uflow/user/rbac/policy/check \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "user-uuid",
    "resource": "projects",
    "action": "write",
    "scope_type": "project",
    "scope_id": "project-uuid"
  }'

Integration Pattern

Use the policy check endpoint from your backend services to make authorization decisions:

Client Request → Your API → Policy Check → Allow/Deny → Response

This enables externalized authorization where your services delegate permission decisions to the AuthSec RBAC engine.