---
title: "Permit.io vs WorkOS FGA vs Ory: SaaS Authorization in 2026"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-05-16"
category: "Technology"
tags:
  - SaaS authorization
  - Permit.io review
  - WorkOS FGA
  - Ory authorization
  - RBAC ABAC ReBAC
excerpt: "Authorization is the part of your SaaS that nobody thinks about until it breaks. And when it breaks, it is a security incident. These three platforms take fundamentally different approaches to solving it."
reading_time: "14 min read"
canonical_url: "https://kanopylabs.com/blog/permit-io-vs-workos-fga-vs-ory-authorization"
---

# Permit.io vs WorkOS FGA vs Ory: SaaS Authorization in 2026

## Authorization Is Not Authentication, and Getting It Wrong Is Expensive

Authentication answers "who are you?" Authorization answers "what are you allowed to do?" Most developers spend weeks getting authentication right and then bolt on authorization as an afterthought. A few if-statements in middleware, a role column in the users table, maybe a permissions array in the JWT. It works until your first enterprise customer asks for custom roles, or a support rep accidentally deletes production data because nobody scoped their access properly.

The cost of getting authorization wrong goes beyond security incidents. A leaked admin endpoint or a broken access check can expose customer data across tenants, violate SOC 2 controls, and end up in a breach disclosure. We have seen startups lose six-figure enterprise deals because they could not demonstrate proper role-based access during a security review. If you are building [multi-tenant SaaS](/blog/multi-tenant-saas-architecture), authorization is load-bearing infrastructure, not a feature you tack on later.

In 2026, three platforms dominate the external authorization space: Permit.io, WorkOS FGA, and Ory. Each takes a fundamentally different approach to the problem. Permit.io gives you a visual policy editor built on open-source engines. WorkOS FGA gives you a Zanzibar-style relationship graph deeply tied to their auth platform. Ory gives you open-source building blocks you assemble yourself. The right choice depends on your team, your product, and how much complexity you are willing to own.

![Security compliance dashboard representing SaaS authorization and access control systems](https://images.unsplash.com/photo-1563986768609-322da13575f2?w=800&q=80)

## Authorization Models: RBAC, ABAC, and ReBAC Explained

Before comparing platforms, you need to understand the three authorization models they support. Most real-world applications end up using a combination of all three.

### RBAC: Role-Based Access Control

RBAC is the model everyone starts with. Users are assigned roles (admin, editor, viewer), and roles map to permissions (create:post, delete:user, read:analytics). It is simple, auditable, and covers 80% of use cases. The limitation is that RBAC is coarse-grained. You can say "editors can edit posts" but not "editors can only edit their own posts" or "editors can only edit posts in their department." When you start adding conditional logic on top of roles, you have outgrown pure RBAC.

### ABAC: Attribute-Based Access Control

ABAC makes decisions based on attributes of the user, the resource, and the environment. Instead of "editors can edit posts," you write "users with role=editor AND department=marketing can edit posts where status=draft AND created_after=2026-01-01 during business_hours." ABAC is powerful but complex. Policies are harder to write, harder to test, and harder for non-technical stakeholders to understand. AWS IAM policies are essentially ABAC, and if you have ever debugged a 40-line IAM policy to figure out why a Lambda cannot read from S3, you know the pain.

### ReBAC: Relationship-Based Access Control

ReBAC, popularized by Google's Zanzibar paper, models authorization as a graph of relationships. Instead of attaching permissions to roles, you define relationships between entities: "User X is an editor of Document Y," "Document Y belongs to Folder Z," "Folder Z is owned by Organization W." Permission checks traverse this graph. "Can User X read Document Y?" becomes "does a path exist from User X to Document Y through relationships that grant read access?" This is how Google Drive, Google Docs, and most modern collaboration tools handle sharing.

ReBAC excels at hierarchical permissions and resource sharing. It naturally handles "editors of a folder can edit all documents in that folder" without writing explicit rules for every document. The tradeoff is that you need to maintain a relationship graph, and graph traversal latency matters when you are checking permissions on every API request.

Understanding which model fits your product is step one. If you have simple roles and flat resources, RBAC is enough. If you need fine-grained conditions, add ABAC. If your product has shared resources, nested hierarchies, or organizational structures, you need ReBAC. Most B2B SaaS products need at least RBAC plus some ReBAC for resource-level permissions. If you are still sorting out your [authentication layer](/blog/how-to-build-secure-authentication), handle that first before layering on authorization.

## Permit.io: The Visual Policy Editor That Actually Works

Permit.io is the most developer-friendly authorization platform on the market, and its killer feature is the no-code policy editor. You define roles, resources, and permissions through a clean UI, and Permit generates the underlying policies in OPA (Rego) or Cedar. Non-technical product managers can configure new roles and permissions without writing code or waiting for an engineering sprint.

### Architecture

Permit runs a lightweight Policy Decision Point (PDP) as a sidecar container in your infrastructure. Your application sends authorization checks to the local PDP, which evaluates policies and returns allow/deny decisions. Policies are synced from Permit's cloud control plane to your local PDP, so authorization checks never leave your network. Typical latency is 1 to 5 milliseconds per check, well within the sub-10ms target you need for inline authorization.

### Model Support

Permit supports RBAC, ABAC, and ReBAC out of the box. You start with RBAC (define roles and permissions in the UI), add ABAC conditions when needed (attribute-based rules written in the policy editor), and layer on ReBAC for resource-level relationships (user X is owner of resource Y). The progression feels natural. You do not have to choose your model upfront or rearchitect when your needs evolve.

### Pricing

Free tier: up to 1,000 monthly active users with full RBAC/ABAC/ReBAC support. Growth: $50 per month for up to 10,000 MAU. Enterprise: custom pricing for dedicated PDPs, advanced audit logs, and SLA guarantees. The free tier is genuinely usable for early-stage products, not a crippled trial designed to force upgrades.

### Standout Features

- **GitOps integration:** Policies can be managed in Git and deployed through CI/CD, giving you policy-as-code alongside the visual editor

- **Audit log:** Every authorization decision is logged with full context (who, what, when, why), making SOC 2 compliance straightforward

- **User management UI:** Built-in interface for assigning roles and managing user permissions, which you can embed in your application or use internally

- **Multi-tenant support:** First-class tenant isolation with per-tenant role configurations

### Limitations

Permit is a managed service. If you need to run everything on-premise with zero external dependencies, this is not the right fit. The Cedar/OPA policy language underneath is powerful but has a learning curve when you need to write custom policies beyond what the UI supports. And while the free tier is generous, costs can climb quickly past 10,000 MAU for products with large user bases.

![Developer implementing authorization policies and access control code in an IDE](https://images.unsplash.com/photo-1555949963-ff9fe0c870eb?w=800&q=80)

## WorkOS FGA: Zanzibar for B2B SaaS

WorkOS Fine-Grained Authorization is built on the Zanzibar model and deeply integrated with WorkOS's authentication, SSO, and directory sync products. If you are already using WorkOS for enterprise auth, FGA slots in seamlessly. If you are not, the tight coupling becomes a constraint.

### Architecture

WorkOS FGA stores authorization data as a relationship graph (tuples of user-relation-object). Permission checks traverse this graph to determine access. The system is designed for low-latency reads, using aggressive caching and denormalization to keep check latency under 10 milliseconds even for deep graph traversals. You define an authorization model (similar to OpenFGA's DSL) that specifies object types, relations, and how permissions are computed from relationships.

### Model Support

FGA is ReBAC-first. You model everything as relationships and derive permissions from graph traversal. RBAC is implemented as a special case of ReBAC (a role is just a relationship between a user and an organization). ABAC-style conditions (called "contextual tuples" or "conditions" in the Zanzibar world) are supported but feel bolted on rather than native. If your primary need is attribute-based rules, WorkOS FGA is not the most natural fit.

### Integration with WorkOS Ecosystem

The real value of WorkOS FGA is the integration with the broader WorkOS platform. Directory sync automatically creates organizational relationships in FGA when users are provisioned through SCIM. SSO login events can trigger permission checks. Admin Portal lets your customers manage their own roles and permissions. If you are selling to enterprises with complex organizational structures (departments, teams, projects, shared resources), WorkOS gives you the full stack: SSO, directory sync, and fine-grained authorization in one platform.

### Pricing

WorkOS FGA pricing is bundled with the WorkOS platform. The base plan starts at $150 per month and includes SSO, directory sync, and FGA. You cannot buy FGA standalone. For B2B SaaS products that need enterprise-ready auth and authorization, the bundle is cost-effective. For products that only need authorization, paying $150 per month minimum when Permit's free tier covers the basics is a harder sell.

### Limitations

Vendor lock-in is real. WorkOS FGA is proprietary, and migrating away means rebuilding your entire authorization model. The Zanzibar-style DSL for defining authorization models has a significant learning curve compared to Permit's visual editor. And because FGA is ReBAC-native, modeling pure ABAC scenarios requires workarounds that can feel awkward. If you want a deeper comparison of the auth protocols that feed into these systems, our [SSO protocol comparison](/blog/sso-saml-vs-oauth-vs-oidc-for-saas) covers the authentication side in detail.

## Ory: Open-Source Flexibility at the Cost of Engineering Time

Ory takes the opposite approach from Permit and WorkOS. Instead of a managed platform, Ory gives you open-source building blocks: Ory Keto for authorization (inspired by Zanzibar), Ory Kratos for identity, Ory Hydra for OAuth2/OIDC, and Ory Oathkeeper for API gateway authorization. You can self-host everything for free or use Ory Network, their managed cloud offering.

### Ory Keto: The Authorization Engine

Keto implements the Zanzibar model with a gRPC and REST API for managing relationship tuples and checking permissions. It is fast, well-documented, and production-tested. You define namespaces (object types), relations, and permission rules in a TypeScript-like configuration language. Keto stores relationships in PostgreSQL or CockroachDB and supports horizontal scaling for high-throughput workloads.

### Model Support

Like WorkOS FGA, Keto is ReBAC-native. RBAC is modeled as relationships, and ABAC requires supplementing Keto with additional logic in your application layer or API gateway. Ory Oathkeeper can handle some ABAC-style rules at the gateway level, but the integration between Oathkeeper and Keto requires manual configuration.

### Self-Hosted vs. Ory Network

Self-hosting Ory is free and gives you complete control. You run Keto as a container alongside your application, manage your own database, handle your own scaling, and own your uptime. This is ideal for regulated industries (healthcare, finance) where data residency requirements prohibit sending authorization data to third-party clouds. The tradeoff is operational overhead: you are responsible for upgrades, monitoring, backup, and scaling. Budget 2 to 4 weeks for initial setup and integration, plus ongoing maintenance.

Ory Network is the managed alternative. Pricing starts at $29 per month for development environments and scales based on usage. Production plans are custom-quoted. The managed version handles infrastructure but still requires you to write and manage your own authorization models.

### Standout Features

- **Full stack:** Keto + Kratos + Hydra gives you identity, authentication, and authorization from one ecosystem, all open-source

- **No vendor lock-in:** You own the code, the data, and the infrastructure. Migration means moving containers and a database

- **Community:** Active open-source community with 40,000+ GitHub stars across Ory projects

- **Performance:** Keto handles millions of permission checks per second when properly scaled, with sub-millisecond latency on cached lookups

### Limitations

Ory requires the most engineering effort of the three options. There is no visual policy editor. There is no built-in audit log (you build your own). Multi-tenant permission models require careful namespace design. And integrating Keto with Kratos and Oathkeeper into a cohesive authorization system is a meaningful engineering project. If your team has two backend engineers, Ory might consume 20% of their capacity for the first quarter. If you have ten engineers, the investment is more manageable.

![Kanban project board representing engineering effort and sprint planning for authorization implementation](https://images.unsplash.com/photo-1512758017271-d7b84c2113f1?w=800&q=80)

## Performance, Caching, and the 10ms Budget

Authorization checks happen on every API request. Sometimes multiple checks per request (can this user access this resource AND perform this action AND view this field?). If each check takes 50 milliseconds, a page load with 10 authorized resources adds half a second of latency. Your users will notice. Your p99 latency will spike. Your infrastructure costs will climb as you scale horizontally to compensate.

The target is sub-10ms per authorization check, measured at the p99. All three platforms can hit this target, but the strategies differ.

### Permit.io Caching

Permit's local PDP sidecar caches policies and data in memory. Authorization checks are evaluated locally without network round-trips to Permit's cloud. Policy updates are pushed to the PDP via a persistent connection, with typical propagation times under 5 seconds. For most applications, the PDP handles thousands of checks per second on a single container with sub-5ms latency.

### WorkOS FGA Caching

WorkOS FGA uses server-side caching and query optimization. Relationship graph traversals are precomputed and cached based on access patterns. The system automatically denormalizes frequently-checked permissions into lookup tables for constant-time access. You do not manage the caching layer directly. WorkOS handles it, but you lose visibility into cache hit rates and eviction behavior.

### Ory Keto Caching

Keto supports multiple caching strategies. In-memory caching on the Keto instance handles repeated checks for the same user-resource pair. Database-level query caching reduces redundant graph traversals. For high-throughput scenarios, you can add a Redis layer between your application and Keto to cache permission decisions with a configurable TTL. You own the caching strategy, which means you can optimize aggressively but also means you carry the complexity.

### Testing Authorization Rules

This is the area where most teams cut corners, and it is where authorization bugs originate. You need automated tests that verify: positive cases (users with permission can access resources), negative cases (users without permission are denied), edge cases (what happens when a user has conflicting roles, or when a resource has no owner, or when a tenant's custom role grants unexpected permissions).

Permit.io provides a built-in policy testing framework that lets you write test scenarios in the UI and run them against your policy configuration. WorkOS FGA supports test tuples that let you simulate authorization checks without modifying production data. Ory Keto requires you to write your own integration tests, typically using the gRPC client to load test fixtures and verify permission checks against expected outcomes.

Regardless of platform, invest in authorization testing early. A misconfigured role that grants admin access to all users in a tenant is the kind of bug that automated tests catch in CI and manual testing misses until a customer reports it.

## Multi-Tenant Permission Models and Audit Logging

Every B2B SaaS product is multi-tenant, and multi-tenancy adds a dimension to every authorization decision. It is not just "can this user edit posts?" It is "can this user edit posts in this tenant, with the role assigned by this tenant's admin, subject to this tenant's custom permission configuration?"

### Tenant Isolation

Permit.io handles multi-tenancy natively. Tenants (called "environments" or "projects" in Permit) are first-class objects. Each tenant can have its own role definitions, permission assignments, and resource configurations. The PDP automatically scopes authorization checks to the correct tenant based on context. This is the simplest multi-tenant model of the three.

WorkOS FGA models tenants as objects in the relationship graph. An organization has members, members have roles within that organization, and permissions are scoped through the organizational relationship. This works well for hierarchical organizations (company, division, team) but requires careful schema design to prevent cross-tenant data leakage.

Ory Keto uses namespaces to separate tenants. Each tenant can have its own namespace with isolated relationship tuples, or you can use a shared namespace with tenant-scoped object IDs. The shared approach is simpler but requires vigilant prefixing to prevent cross-tenant queries. The isolated approach is safer but increases operational complexity as your tenant count grows.

### Audit Logging

SOC 2, ISO 27001, and HIPAA all require audit trails for access control decisions. Your authorization system needs to log every permission check with enough context to answer: who requested access, to what resource, at what time, and what was the decision?

Permit.io includes comprehensive audit logging in paid plans. Every decision is logged with the full policy evaluation context, exportable to your SIEM or log aggregation platform. WorkOS provides audit logs through their Admin Portal and API, including authorization decisions alongside authentication events. Ory Keto does not include built-in audit logging. You implement it yourself by wrapping Keto API calls in your application layer and writing decision logs to your own storage. This is typically 1 to 2 days of engineering work for a basic implementation, plus ongoing maintenance to ensure log completeness and reliability.

### Custom Roles and Permission Delegation

Enterprise customers will ask to create their own roles. They want their admin to define a "Regional Manager" role that can view reports for their region but not edit global settings. All three platforms support this, but the implementation effort varies significantly. Permit.io's UI lets you build a self-service role management page for your customers in a day, using their embeddable components. WorkOS exposes role management through the Admin Portal, which you embed in your application. Ory requires you to build the entire role management UI yourself, with API calls to Keto to create the underlying relationships.

## Honest Recommendations by Use Case

After integrating all three platforms across different client projects, here are the recommendations we give to the teams we work with.

### Choose Permit.io If:

- **You are an early-stage startup** and need authorization that works now, not after a two-week implementation sprint. The free tier covers you to 1,000 MAU, the visual editor means your product team can manage permissions without engineering tickets, and the local PDP keeps latency low.

- **Your team is small (2 to 5 engineers)** and cannot afford to dedicate someone to authorization infrastructure. Permit handles the hard parts and lets you focus on your product.

- **You need RBAC today but know you will need ABAC and ReBAC later.** Permit's progressive model support means you do not have to rearchitect when your needs evolve.

- **Non-technical stakeholders need to manage permissions.** The no-code policy editor is genuinely the killer feature. No other platform comes close for policy management UX.

### Choose WorkOS FGA If:

- **You are building B2B SaaS that sells to enterprises** and you need SSO, directory sync, and authorization as a unified platform. Buying these separately from three vendors creates integration headaches. WorkOS bundles them.

- **Your authorization model is relationship-heavy.** Organizational hierarchies, shared workspaces, team-based permissions, folder/document ownership. The Zanzibar model excels here.

- **You are already using WorkOS for authentication.** FGA integrates natively with WorkOS auth events and directory sync. Adding authorization takes days, not weeks.

- **Your budget can absorb $150+ per month** for the WorkOS platform. The bundled pricing makes sense if you need the full suite. It does not make sense if you only need authorization.

### Choose Ory If:

- **You need to self-host everything.** Healthcare, finance, government, or any regulated environment where authorization data cannot leave your infrastructure. Ory is the only option among the three that gives you full self-hosted control at zero licensing cost.

- **Your team has strong backend engineering capacity** and you want to own the authorization layer entirely. Ory gives you the most flexibility but demands the most investment.

- **You are building a platform or developer tool** where authorization is a core differentiator and you need deep customization that managed platforms cannot provide.

- **Cost sensitivity is critical at scale.** At 100,000+ users, managed platform fees add up. Self-hosted Ory costs you infrastructure and engineering time, but the per-user cost approaches zero.

### The Hybrid Approach

Some teams start with Permit.io for speed, then evaluate whether to migrate to Ory for cost or WorkOS for enterprise integration as they scale. This works because authorization interfaces are relatively thin: your application calls a "check permission" function regardless of which platform evaluates it. Abstracting the authorization check behind an internal interface makes migration feasible without touching your business logic.

The worst approach is building authorization from scratch with custom middleware and database queries. You will spend months reinventing what these platforms provide, introduce security vulnerabilities along the way, and end up migrating to a platform anyway once your first enterprise customer asks for audit logs and custom roles.

If you are building SaaS and need help choosing and implementing the right authorization strategy for your product, [book a free strategy call](/get-started) with our team. We have integrated all three platforms and can help you pick the right one for your specific use case, team size, and growth trajectory.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/permit-io-vs-workos-fga-vs-ory-authorization)*