3366 Members
Join Permit's SlackWorkOS launched Fine-Grained Authorization on February 17, 2026, extending its existing RBAC system with hierarchical, resource-scoped access control. Teams evaluating WorkOS FGA often compare it with other authorization services to find the best fit for their stack. This post covers what WorkOS FGA provides, how Permit.io approaches the same problem, and when each makes sense.
For background on FGA concepts, see What is Fine-Grained Authorization.
According to the WorkOS FGA documentation, FGA keeps the mental model of RBAC while adding hierarchical, resource-scoped access control. The defining feature is that permissions flow down the resource hierarchy automatically: a workspace admin can access all projects and apps within that workspace without needing separate assignments at each level.
WorkOS FGA integrates with other WorkOS products. Per their docs, it works alongside RBAC, SSO, Directory Sync, AuthKit, and IdP role assignment. No migrations are required if you already use WorkOS RBAC. The integration with AuthKit provides role-aware sessions, with organization-scoped roles and permissions embedded directly in access tokens.
On performance, WorkOS states their FGA service provides sub-50ms p95 access checks with high availability and warmed caches to minimize cold starts.
Permit.io is a managed authorization service built on open source policy engines. The control plane runs in Permit's cloud, and decisions run either in a managed Cloud PDP or in Edge PDPs that you deploy in your own network. Permit generates policy as code for OPA (Rego) or Cedar, both open policy languages with their own ecosystems.
According to Permit.io's documentation, the service supports RBAC, ReBAC, ABAC, and PBAC. You define resources, actions, and roles in the Policy Editor, the API, Terraform, or a connected Git repository. OPAL pushes policy and data changes from the control plane to each Edge PDP, which answers checks from its local copy.
Permit.io also provides Permit Elements, embeddable UI components for user management, access requests, approvals, and audit logs. These let your customers' administrators manage their own tenant without tickets to your team.
| Dimension | WorkOS FGA | Permit.io |
|---|---|---|
| Architecture | Extends WorkOS RBAC with resource hierarchy | Managed control plane with local or cloud PDPs |
| Policy language | WorkOS proprietary API and model | Generated Rego (OPA) or Cedar |
| Access models | RBAC with hierarchical resource scoping | RBAC, ReBAC, ABAC, PBAC |
| Integration ecosystem | WorkOS stack (SSO, Directory Sync, AuthKit) | Any IdP; Terraform, GitOps, API, SDK |
| End-user UI components | Not documented as available | Permit Elements (user management, access requests, audit logs) |
| Decision point location | WorkOS cloud | Cloud PDP or self-hosted Edge PDP |
| Policy storage | WorkOS cloud | Control plane plus optional GitOps to your repository |
| Open source components | Not open source | Edge PDP, OPAL, cedar-agent (Apache 2.0) |
Sources: WorkOS FGA docs, WorkOS FGA reference, Permit.io docs, Permit.io policy engines, Permit Elements.
WorkOS FGA uses a proprietary model: you define resource types and role assignments through their API, and WorkOS evaluates access internally. The policy logic stays within WorkOS.
Permit.io generates policy as code in Rego or Cedar. Both are open policy languages: OPA is a CNCF graduated project and Cedar is in the CNCF sandbox. The generated policy can be reviewed in Git, tested with standard tools, and, in principle, reused outside Permit if you change control planes later.
If portability and open standards matter to your team, policy in Rego or Cedar offers more flexibility than a vendor-specific model.
WorkOS FGA decisions run in WorkOS's cloud infrastructure. The WorkOS FGA documentation mentions sub-50ms p95 latency and high availability, but does not document a self-hosted decision point option.
Permit.io supports both a managed Cloud PDP and self-hosted Edge PDPs. According to the Permit.io deployment docs, Edge PDPs run as containers in your network. Checks stay local, and the PDP keeps working from cached policy if the control plane is temporarily unreachable. For teams that need decisions to stay within their VPC, this hybrid model provides more control.
WorkOS FGA models relationships through hierarchical resources. According to their docs, you register structural resources (organizations, workspaces, projects), and permissions inherit down the tree. This covers many SaaS authorization patterns, though the relationship model is simpler than a full graph.
Permit.io's ReBAC support includes relationship tuples, resource roles, and role derivation, following patterns from Google Zanzibar. OPAL pushes relationship data to Edge PDPs so checks run against a local copy. For deep sharing graphs with nested folders, groups, and derived roles, this model provides more flexibility.
WorkOS FGA fits naturally if you already use WorkOS for SSO, Directory Sync, or AuthKit. The products integrate natively, and AuthKit embeds role-aware sessions in access tokens.
Permit.io works with any identity provider. You can use the API, SDKs for Python, Node.js, Go, Java, .NET, and Ruby, a Terraform provider, or GitOps to sync generated policy to your own repository. Changes move through the same pipeline as the rest of your code.
WorkOS FGA does not document prebuilt UI components for end-user access management. If your product requires a UI where customers can manage their own permissions, you would build that yourself.
Permit.io provides Permit Elements, embeddable React components for user management, access requests, approvals, and audit logs. Product managers, support, and customer administrators can manage access without code changes.
The WorkOS pricing page lists usage-based Pay as You Go and custom Annual Credits, but does not publish a separate FGA price or FGA-specific usage rate. AuthKit pricing starts with the first 1 million MAU free, then $2,500 per month for each additional 1 million MAU.
According to the Permit.io pricing page and payment portal, the Community tier is free and includes up to 1,000 MAU, 20 tenants, 3 environments, and 14 days of audit log retention. Pro and Enterprise tiers are usage-based on MAU. Enterprise adds unlimited usage, compliance support (SOC 2 Type II report, HIPAA BAA), multi-cloud and on-prem deployment options, and SLA support.
Comparing costs requires modeling your specific workload, as the units differ.
WorkOS FGA fits best when:
Permit.io fits best when:
A short proof of concept shows more than any comparison table. Take one production-shaped rule, implement it in both services, and test the failure modes: what happens when the control plane or decision service is unreachable? How do you promote a policy change from staging to production? Can someone outside your engineering team understand why a user was allowed or denied?
WorkOS FGA extends the existing WorkOS RBAC system with hierarchical resource scoping and integrates natively with other WorkOS products. Permit.io is a standalone authorization service that generates policy in Rego or Cedar, supports multiple access models, and offers both cloud and self-hosted decision points.
The WorkOS FGA documentation does not describe a self-hosted decision point option. Decisions run in WorkOS cloud infrastructure.
Yes. Permit.io works with any identity provider. You can use WorkOS for authentication and Permit.io for authorization.
Permit.io's ReBAC support includes relationship tuples, role derivation, and synced relationship data at the decision point. WorkOS FGA's hierarchical model covers many SaaS patterns but does not document the same level of relationship complexity.
WorkOS does not publish a separate FGA price. Permit.io's Community tier is free with 1,000 MAU and 20 tenants. For larger workloads, model your MAU, tenants, and requirements, then contact both vendors for quotes.
Co-Founder & VP of R&D at Permit.io
