Schedule a 1x1 with an Oso engineer to get help modeling your authorization system in Oso Cloud.
Find a time →
Create Your First Policy
Select the authorization patterns and use cases supported by your app. Then, download the policy to get started with a working example.
Common in HR and Sales applications, an "Org Chart" model lets managers perform actions that any of their employees can perform. In this pattern, actors form a tree, where permissions flow upwards from employee to manager.
It’s common to arrange resources in hierarchies, where permissions on high-level objects flow down to low-level objects. Documents in Google Drive, for example, inherit permissions from the folders they reside in.
Some applications let the owner of a particular resource share that resource with other users. Github repositories, Google Drive documents, and Notion pages all use this pattern. This is like role-based access control, where the roles are scoped to a single resource.
Groups are named collections of actors, just as roles are named collections of permissions. Using this pattern, you can assign roles and permissions to groups directly, and group members inherit the permissions of their group.
It’s common for applications to group resources by organization (also known as a "tenant" or "client"). Users have a role on an organization, which determines their permissions on each resource inside of it.
Sometimes an application allows its users to create new roles with customizable permissions. In this case, rather than statically defining the roles in the policy, the application can create these custom roles on the fly by defining what permissions they grant.
In a multi-tenant application, resources are often associated with the tenant they belong to. Users may dynamically decide an organization's default role, which all of the organization's members inherit.
Some resources are public, meaning they can be read by anyone. An attribute on a resource can be used to indicate that it is public.
Additional information about a user, such as whether it is an active account, may be used for additional authorization checks. Such information can be provided as an attribute on the user.
A toggle on a resource can turn on and off certain permissions that a specific role has. The state of the toggle can be provided as an attribute on the resource.
Select at least one pattern on the left to build a runnable example.