Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

RBAC is breaking in SaaS authorization. What comes next?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9016
Topic starter  

TL;DR: As SaaS products add nested resources, custom roles, enterprise IdP mapping, and scoped AI workflows, traditional RBAC and schema-driven FGA models break down, according to WorkOS. The real issue is not authorization logic alone but an access model that assumes product structure stays stable long enough to fit a fixed schema.

NHIMG editorial — based on content published by WorkOS: FGA and how WorkOS is rethinking authorization for the next generation of SaaS

By the numbers:

Questions worth separating out

Q: How should security teams prevent role explosion as SaaS products grow?

A: They should design access around resource hierarchy, not around endlessly new role names.

Q: Why do fine-grained authorization models become hard to govern at scale?

A: They become hard to govern when the schema, resource graph, and application logic evolve at different speeds.

Q: What breaks when AI agents inherit a user's full access in SaaS applications?

A: The access boundary collapses, because the agent can act with more authority than the task requires.

Practitioner guidance

  • Map authorization to resource hierarchy early Define the product's stable resource layers before the role list grows.
  • Limit role variants before they multiply Review every new access exception and ask whether it creates a new role or should inherit from an existing scoped role.
  • Keep high-cardinality resources local Avoid syncing every volatile object into a remote authorization layer.

What's in the full article

WorkOS's full post covers the operational detail this post intentionally leaves for the source:

  • The resource hierarchy design patterns used to avoid role explosion across nested SaaS objects.
  • The implementation details for high-cardinality resources that stay local instead of being synced into a remote graph.
  • The enterprise identity mapping examples for Entra, Okta, SSO, and SCIM-driven access.
  • The product-side rollout path for adopting hierarchical authorization without rewriting existing RBAC models.

👉 Read WorkOS's article on hierarchical authorization for SaaS products →

RBAC is breaking in SaaS authorization. What comes next?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8472
 

Authorization sprawl is the governance failure hidden inside product growth. When products move from flat permissions to nested workspaces, projects, and application layers, the access model often lags behind the real structure of the business. That creates the same kind of governance debt we see in NHI programmes: the control looks intact, but it no longer matches how identities actually operate. Practitioners should treat authorization drift as a lifecycle problem, not a one-time design decision.

A few things that frame the scale:

  • 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
  • 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

A question worth separating out:

Q: How do enterprises map IdP groups into resource-scoped access without losing control?

A: They should map directory groups and attributes to specific resource scopes, then keep inheritance rules explicit. That lets enterprise identity stay central while avoiding broad, manual grants that are hard to audit later. The key is to preserve predictable group-to-resource mapping without flattening the hierarchy.

👉 Read our full editorial: WorkOS FGA and the limits of RBAC in SaaS authorization



   
ReplyQuote
Share: