Skip to main content

Documentation Index

Fetch the complete documentation index at: https://www.osohq.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Use Oso Cloud to check whether an actor has a given permission on a resource before reading or writing data. Authorization has two parts:
  • Decisions: Oso evaluates your policies against authorization facts to determine outcomes (allow or deny)
  • Enforcement: Your application acts on the decision (return errors, filter data, etc.)

​
Decision APIs

Oso provides three API patterns:
  1. Explicit Authorization: Check if a user has permission on a resource
  2. List Resources: Get resources a user has permission on
  3. List Permissions: Get permissions a user has on a resource
Check out the authorization check API documentation for more details.

​
Local vs. centralized

Choose the correct API variant based on your authorization data strategy.
  • Local Authorization (*_local): Use when facts live in your own database.
  • Centralized Authorization: Use when facts live entirely in Oso Cloud.
  • If you use Local Authorization at all, always use local APIs. Centralized facts in Oso Cloud still apply to local queries.

​
Implementation Principles

Use consistent object format. Make actor/resource structures predictable: 
const user = { type: "User", id: req.user.id };
const resource = { type: "Repository", id: req.params.repoId };
Handle denials cleanly. Return appropriate HTTP status codes and error messages: 
if (!authorized) {
  return res.status(403).send("Unauthorized");
}
Validate before calling Oso. Check IDs exist and are valid before making API calls. Cache with care. Cache common checks with appropriate TTL to avoid stale permissions.