tell("has_role", user, "editor", document)

Permit.io:

// Assign a role on a resource instance await permit.api.roleAssignments.assign({ user: "alice@example.com", role: "editor", resource_instance: "document:doc-123", tenant: "default" });

For relationship facts:

// Create a relationship tuple await permit.api.relationshipTuples.create({ subject: "user:alice@example.com", relation: "owner", object: "document:doc-123" });

Oso local authorization to PDP sidecar

Oso's local authorization mode (embedded engine) maps to running the Permit PDP as a sidecar container.

The PDP (Policy Decision Point) runs as a container alongside your application. Authorization checks go to localhost with sub-millisecond latency:

const permit = new Permit({ token: "<YOUR_API_KEY>", pdp: "http://localhost:7766" // Local PDP sidecar });

Start the PDP container:

docker run -d
-p 7766:7000
--env PDP_API_KEY=<YOUR_API_KEY>
permitio/pdp-v2:latest

The PDP receives policy updates automatically and evaluates checks locally. Your application never waits on a network call to a remote authorization service during permission checks.

A production migration requires more than code changes. Here is a structured approach:

Export or document all your Polar policies. Identify:

Recreate your authorization model in Permit using the UI or Terraform:

Terraform example

resource "permit_resource" "document" { key = "document" name = "Document"

actions = { read = {} write = {} delete = {} } }

resource "permit_role" "editor" { key = "editor" name = "Editor" permissions = ["document:read", "document:write"] }

Permit also provides a web UI for modeling resources, roles, and policies visually if you prefer that workflow.

Run both authorization systems in parallel during a transition period:

async function checkWithComparison(user, action, resource) { const [osoResult, permitResult] = await Promise.all([ osoClient.authorize(user, action, resource).catch(() => false), permit.check(user, action, resource).catch(() => false) ]);

if (osoResult !== permitResult) { logger.warn("Authorization mismatch", { user, action, resource, oso: osoResult, permit: permitResult }); }

// Return Oso result during shadow period return osoResult; }

Track mismatches and investigate each one. The goal is zero mismatches before cutting over.

Once shadow running shows consistent results:

Verify your audit trail works with the new system. Permit logs every authorization decision with:

Review the Audit Log in the Permit dashboard or export logs to your SIEM.

One consideration when choosing an authorization platform is whether it locks you into a proprietary policy language.

Permit.io runs on open-source policy engines under the hood. The PDP uses Open Policy Agent (OPA) for policy evaluation and supports Cedar policies for teams that prefer that syntax. OPAL (Open Policy Administration Layer) handles real-time policy and data synchronization.

This means your policies are expressed in open standards (Rego, Cedar) rather than a proprietary language. If you ever need to move again, your policy logic is portable.

If you are migrating from Oso Cloud, we are offering extended quotas to give you time to migrate properly.

Offer: Oso customers get 25% extra on every Permit (classic) plan quota listed on the Permit Pricing page for 12 months.

For example, the Permit classic Free plan includes 20 tenants, 3 environments, 14 days of logs, and 1,000 MAU. With this offer, those quotas increase by 25% for your first year.

Enterprise-tier customers also receive hands-on migration assistance from our team.

To claim this offer, book a migration consultation and mention you are migrating from Oso Cloud.

If you need help with migration planning, schedule a call with our team.

According to Oso's announcement, Oso Cloud will continue to operate as usual after the acquisition by Tiny Ltd. However, most of the team is joining Temporal to work on agent security there. The long-term roadmap and support posture are unclear.

The open-source Oso library (standalone Polar engine) was deprecated in December 2023. Oso Cloud was the supported path forward. With the team transitioning, there is no actively maintained Oso option.

Timeline depends on policy complexity. Simple RBAC models can migrate in days. Complex ReBAC with many relations and ABAC conditions may take weeks of shadow running to validate decision parity.

No. Permit uses a visual Policy Editor, API, and Terraform provider for policy definition. The underlying engines use Rego (OPA) and Cedar, both open standards. The mapping table in this guide shows how to translate each Polar concept.

The Permit PDP runs as a local sidecar container. Authorization checks are local network calls (typically sub-millisecond) and do not depend on reaching a remote service. This is similar to how Oso's local mode worked.