Authorization Model

Thauth is designed around explicit permission pairs rather than inferred policy rules.

Features and actions

A feature identifies the protected area, such as billing or projects.

An action identifies the operation inside that feature, such as read, write, or delete.

Together they form the unit of authorization.

Roles

Roles bundle feature-action pairs into reusable sets.

This keeps application code simple because the check endpoint does not need to know which role produced the permission. It only needs the requested pair.

Subjects

A subject is the principal being evaluated.

Most applications use a user identifier such as user_123, but a service account or machine identity works the same way.

Tenant scoping

Every decision can optionally include a tenant.

Use tenant scope when a subject may have different access across customer workspaces or organizations.

Overrides

Overrides are the escape hatch.

Use them when one subject needs a targeted allow or deny without changing the shared role definition for everyone else.

Decision output

Every check returns:

• allowed: whether the request should be permitted
• reason: the evaluation result source, such as a role match or a default deny