How Oso Polar policies map to RBAC, ReBAC and ABAC if you're planning a move

Tiny Ltd completed its acquisition of Oso Cloud on October 1, 2026, and most of the Oso team is joining Temporal. Oso says Oso Cloud will keep operating as usual. If your production authorization runs on it, this is still a good moment to write down what your Polar policies actually do, while you have working knowledge of them.

Most Polar files mix three patterns. Sorting them first makes any target easier to pick:

• Role grants inside a resource block, like "push" if "admin";. This is plain RBAC: a resource, its actions, and roles that hold permissions.
• Role derivation through a relation, like "reader" if "member" on "organization";. In ReBAC terms you need the relation defined on the resource type, plus the actual relationship data (repo-1 belongs to org acme) synced from your app.
• Attribute conditions in allow rules, such as user.department == "engineering" and doc.classification != "restricted". Those attributes either get synced ahead of time or passed in with each check.

The call site changes least. oso.authorize(user, "read", document) becomes one check with user, action and resource, plus a tenant if you're multi-tenant. List filtering and "which resources can this user see" queries need their own mapping, so inventory those endpoints early.

One more thing to look for: the open-source Oso library (the standalone Polar engine) was deprecated in December 2023, in case an older service still depends on it.

Disclosure: I work at Permit.io. My colleague Ze'ev Manilovich wrote the full guide, with Permit SDK examples for each pattern and a step-by-step migration plan:

https://www.permit.io/blog/migrate-from-oso-to-permit?utm_source=devto&utm_medium=social&utm_campaign=oso-migration&utm_content=authbyexample-article