FGA : How WorkOS Is Rethinking Authorization for the Next Generation of SaaS

Authorization looks simple at first. In practice, it is one of the hardest and fastest-changing parts of modern software. It sits in the path of nearly every user action and determines who can see, edit, collaborate, automate, or purchase anything inside a product.

Most SaaS teams begin with basic RBAC and quickly outgrow it. As adoption increases, the authorization model expands. What used to take ten years now happens in less than 2 years. Teams patch their RBAC systems, add exceptions, multiply roles, and eventually face full-scale rewrites.

Authorization becomes a bottleneck for product delivery instead of an enabler.

After working with tens of thousands of organizations, we see the same pattern across nearly every SaaS company. Traditional approaches, such as RBAC, policy engines, resource-based access control, or graph-based models, all solve parts of the journey, but none adapt smoothly to how products actually evolve. The deeper issue is that SaaS systems change constantly, while most authorization solutions expect stability.

That mismatch creates friction, migrations, and complexity as the product grows. FGA is our answer. It builds on the basic RBAC model already used by thousands of WorkOS customers and extends it into a flexible, fine-grained system that grows naturally with the application, without schema languages, migrations, or large rewrites.

The Natural growth pattern of a B2B SaaS product

Most SaaS products begin with simple user-level permissions. This works on day one. But as adoption increases, the model expands. A typical progression looks like this:

• Starts with a simple permission model
• Organizations and tenants form as the customer base grows
• Admin & Billing roles are added
• Teams request custom roles with granular permissions
• Group-based collaboration becomes a core requirement
• Departments or business units introduce a model hierarchy
• New application resources like workspaces, projects, applications, and other nested resources enter the model
• New product SKUs introduce additional resource types
• Regulated industries require compliance-focused access rules
• Large enterprises and subsidiaries bring parent-child organizational structures
• Requests to start automating access provisioning from Identity Providers (IdP)
• AI agents begin performing scoped actions for users

Each step fundamentally changes the shape of the authorization graph. What began as a flat set of permissions becomes a deeply nested, constantly shifting structure.

Every new feature forces the model to evolve

As the product grows, every new feature affects authorization. A new resource type may require new inheritance rules. A new enterprise segment may require exceptions that break old assumptions.

A new collaboration model may require a level of granularity the system was never designed to support. This is why teams often rebuild authorization multiple times. The early model no longer matches the product's reality.

Where RBAC works and where it starts to break

RBAC is usually the first authorization model a SaaS product adopts. It is simple, familiar, and effective for early needs.It works well when you have:

• A small set of permissions
• Flat user roles like Admin, Member, Viewer
• No resource-specific access
• Limited collaboration surfaces
• Few enterprise requirements

The model is clean at this stage: assign a role, grant its permissions.Problems begin as soon as resource scoping comes into play. A user might be an Admin for one workspace, an Editor for a single project, and only a Viewer for a specific app.

Flat RBAC cannot express these differences without creating dozens of role variants. The model quickly strains when you introduce:

• Resource hierarchies
• Inheritance across parent and child entities
• Department or project-specific access
• Customer-specific exceptions
• Cross-functional collaboration within a tenant

Teams respond by multiplying roles. Admin becomes Workspace Admin, Project Admin, App Admin, and many more. The role list grows faster than the product itself.

At this point, RBAC no longer aligns with the application's structure. The product becomes hierarchical while the authorization model stays flat. The result is complexity, special cases, and eventually a full rewrite. This is the inflection point where teams start looking for something more flexible.

Why FGA needs a rethink

Once RBAC starts breaking down, most teams look to Fine-Grained Authorization (FGA) as the natural next step. It promises the flexibility to model users, groups, and deeply nested resources.

And it does deliver that power. But adopting FGA often introduces new challenges. Common pain points include:

• Learning a new domain-specific language (DSL) or query language
• Designing and maintaining a schema that must evolve as the product evolves
• Keeping the entire application graph and high cardinality resources synced with an external system
• Introducing mental models that are difficult for product teams to apply
• Making onboarding harder because developers must understand both the FGA concepts and the company-specific access rules
• Replacing or working around existing RBAC systems, which makes adoption costly
• Mapping enterprise IdP resources to ever-changing FGA structures

While it is possible to update schemas and add new rules over time, this often creates friction. Changes may require data migrations, heavy rule reviews, or careful analysis to understand how new relationships will affect existing access.

As your product grows more complex, FGA complexity tends to grow right along with it. This is the real issue. Traditional FGA assumes you can anticipate your long-term authorization model.

But in a real SaaS product, new resource types, collaboration patterns, enterprise requirements, and AI-driven workflows appear continuously. The access model shifts with every release.

At WorkOS, we are designing an authorization system to address this exact problem. It gives you the flexibility of a graph-based system while keeping the simplicity of RBAC. No DSLs to learn. No full permission rewrites. No architectural resets. It evolves as your product evolves.

Introducing FGA

FGA extends the straightforward RBAC model to support nested, resource-scoped permissions. It brings hierarchical authorization without losing the speed and simplicity teams depend on.

The design reflects direct feedback from more than 50 enterprise SaaS teams who outgrew flat RBAC and discovered that traditional FGA introduced more complexity than it solved. Most SaaS products develop deeper structure—workspaces, projects, apps, pipelines, or other custom entities.

FGA brings these structures directly into the authorization model so access can match the shape of the product, without a DSL, schema language, or graph layer.

The shift is simple: FGA extends RBAC across your product’s resource hierarchy. You define the resource types that make up your application, and roles can be assigned to specific resource instances at any layer.

There are no new languages or schemas to learn. Inheritance, scoping, and permission propagation happen automatically, preventing role explosion and eliminating the edge-case rules that normally appear as products grow. Key capabilities include:

• Up to 5 layers of hierarchical resource types with multiple types per layer, aligning with real product structure
• Resource-scoped roles that stay focused, predictable, and easy to understand
• Automatic inheritance for clean parent-to-child permission flow
• Unified APIs and native SDKs for resource definition, role assignment, and access checks
• Automatic cleanup and guardrails that prevent orphaned assignments, invalid hierarchies, and lingering permissions as resources change

Developers continue to work with the same RBAC patterns they know, simply applied at more granular levels. Resource instances are registered as they appear in the application, and FGA ensures the authorization graph stays consistent without custom modeling or rewrites.

FGA integrates seamlessly with all WorkOS products, including SSO, SCIM, and AuthKit (though you can also use it without WorkOS integrations). There’s no migration required for existing RBAC customers–your current model continues to work as-is.

You can adopt FGA whenever you’re ready, without rewriting roles or restructuring your data. This lets organizations start with simple RBAC, ship quickly, and layer in resource hierarchies or more advanced access patterns over time.

As product requirements grow, teams can enable FGA capabilities incrementally, without disrupting their existing authorization flow.

How FGA maps to real SaaS architectures

Most SaaS products follow a natural hierarchy of resources, such as:

• Organizations
• Workspaces
• Accounts
• Projects
• Applications
• Pipelines
• Spaces
• Repositories

FGA allows developers to model these authorization hierarchies directly in WorkOS. Resource types can be defined to mirror the product’s structure, and developers can specify how permissions should flow through that hierarchy.

This includes configuring inheritance policies so that access can cascade automatically or remain tightly scoped. A Workspace Admin can inherit access to all projects in that workspace.

A Project Editor can modify only the project to which they are assigned. An App Auditor can view only the specific application inside a project. These patterns can be represented without custom graph infrastructure, edge synchronization, or one-off authorization logic.

FGA turns real product relationships into a predictable, maintainable, easy-to-understand, fast-to-evaluate, and simple-to-evolve authorization model as the application grows.

Handling high-cardinality resources in FGA

High cardinality resource types introduce one of the most subtle but serious anti-patterns in traditional Zanzibar inspired FGA systems: syncing millions of rapidly changing resource instances to an external authorization system.

As cardinality increases, so does the probability of drift, failed updates, or out-of-sync edges, especially when these resources sit directly in the application’s hot path.

Pushing each creation, updates, or deletion over the network to a third-party system adds latency and operational fragility at the exact points where products need maximum speed and reliability.

WorkOS FGA takes a different approach. Instead of treating every individual resource as an external entity that must be synced, applications store high-cardinality resource types locally and register only the stable parent resource types inside WorkOS.

This keeps authorization fast, strongly consistent, and local to the application’s core workflows, while WorkOS handles the complex hierarchical logic at the parent layer. The result is the best of both worlds: a clean, expressive authorization model without forcing high-traffic resources to depend on remote calls, and an architecture that remains performant, resilient, and simple to evolve as the product grows.

Making authorization work for the enterprise

Enterprise customers expect more than basic authorization. They want automated access control, predictable governance, and lifecycle management that aligns with their internal identity systems.

Most importantly, they want their IdP to stay at the center of how access is granted and maintained. FGA supports these needs through deep integration with WorkOS products, including SSO, Directory Sync, and IDP role mapping.

This enables two core enterprise workflows. First, enterprises want to map their IdP groups directly to application user groups so teams can collaborate within the product using the same structure they use internally.

For example, an Entra or Okta group representing the Finance team can be mapped to a workspace or application-level role, ensuring users arrive with the correct access from day one.

Second, enterprises prefer to automate access to deeper, nested resources by mapping IdP groups or user attributes into resource-scoped roles.

Attributes such as department, cost center, or job function can automatically assign roles at the workspace, project, or application level. This removes manual permission management and keeps access in sync with the enterprise’s directory. Examples include:

• Mapping Entra groups to workspace roles
• Assigning Okta attributes to project editor roles
• Propagating custom IDP policies into hierarchical permissions

These capabilities enable enterprises to extend their identity systems to support fine-grained authorization, creating a seamless bridge between IdP-driven governance and resource-based access control.

AI, agents, and the future of access control

Applications are now moving toward agent-driven actions and AI-powered features. This introduces new authorization challenges.

• Agents must not inherit a user's full permissions.
• They must operate with scoped, time-limited access.
• Access checks must be deterministic inside probabilistic systems.
• Document retrieval for RAG must be filtered by authorization before being passed to an LLM.

FGA provides the building blocks for creating safe AI-powered systems. Applications can check fine-grained access for every document, scope permissions for task-oriented bots, and enforce policy boundaries cleanly.Authorization becomes a guardrail system that protects the enterprise while enabling AI-driven automation.

Performance and scale as first-class requirements

Fine-grained permissions are only useful if checks are extremely fast. Every API call requires an authorization decision, which means the access system must be:

• sub 50 millisecond p95
• strongly consistent
• warm cached for high concurrency
• available globally
• resilient to spikes

FGA is engineered to meet these requirements without requiring customers to build caching layers, indexing pipelines, or bespoke denormalized systems.

A complete solution that adapts as you scale

With FGA, teams do not need to learn every authorization pattern, stitch together multiple systems, or redesign their model each time the product evolves. WorkOS handles the complexity, the integrations, and the edge cases behind the scenes. Developers get a single, unified interface for defining resources, assigning roles, managing inheritance, and connecting to enterprise identity systems.

Teams can begin with simple RBAC, introduce resource types as their product matures, add inheritance when they bring in hierarchies, integrate with IDPs for enterprise workflows, and layer on custom roles or contextual logic when needed. Each step builds on the last without rewriting authorization or migrating data.This is an evolving solution that grows with the application.

WorkOS provides the complete authorization foundation so that teams can stay focused on shipping product while the system adapts naturally to new requirements.