The State of Authorization - 2025

We Asked 200+ Developers About the Future of Access Control. Here’s What They Said

Access control, specifically authorization, is changing—are we, the developers, keeping up?

We surveyed 200+ developers with hands-on experience building and scaling authorization in modern software stacks. We wanted to know what models they’re using, which tools they trust, and where they’re running into friction.

In this post, we’ll unpack the results of this survey and share our insights about the results. In this post, we’ll unpack the results of that survey and share our own commentary and insights.

This data gives us a fresh look at how developers are approaching authorization in 2025—and where we believe the biggest opportunities lie.

Let’s look at the numbers -

The State of Authorization Today

If you’re building authorization in 2025, chances are you’re using Role-Based Access Control (RBAC)—and chances are even higher that you’ve built the whole thing yourself.

Out of all the developers we surveyed:

• 94.7% have used Role-Based Access Control (RBAC) at some point.
• 86.6% say RBAC is the model their platform uses today.
• And 62.2% have built a custom in-house solution for managing authorization

None of this is shocking. RBAC has long been one of the most common access control methods. It’s familiar, relatively easy to understand, and well-supported by most identity providers and access management tools.

RBAC nowadays is basically a synonym for authorization. It’s what everyone defaults to, but it also means people are carrying its limitations even when their apps have outgrown it.

Its simplicity makes it easy to adopt early on, but that same simplicity becomes a constraint as systems grow more complex or collaborative.

The high number of custom implementations points to another common reality:

Most teams aren't building their own auth layers because they want to—they're doing it because existing tools don’t fit cleanly into their architecture or workflow.

Especially in distributed or microservices-based environments (which 58.2% of respondents reported using), RBAC starts to break down, and stitching together roles across services becomes a maintenance burden.

Despite all that, RBAC continues to dominate—not because it solves everything, but because it’s the only thing many teams feel confident implementing with limited time and resources.

What’s Gaining Ground

While RBAC still dominates, the survey data shows growing interest in more expressive and flexible models, particularly relationship and attribute-based access control.

Among respondents:

• 41.5% have used Attribute-Based Access Control (ABAC) in the past.
• 27.1% have tried Relationship-Based Access Control (ReBAC).
• 30.3% reported experience with Policy-Based Access Control (PBAC).

ABAC adoption was higher than expected. With nearly half of respondents having used it before, it’s clear that many teams have moved beyond role-only models and are experimenting with attribute- or context-aware policies. While ABAC doesn’t get the same attention as newer models, it’s often the most practical way to add granularity without changing the foundation of an RBAC-based system.

ReBAC, on the other hand, is trending up—driven in part by Google Zanzibar and tools like OpenFGA. What’s interesting is that ReBAC seems to be gaining traction not as a replacement for RBAC but as an extension of it. Teams are starting to model permissions based on dynamic relationships between users and resources—without giving up the familiar concept of roles.

This distinction matters. Many applications don’t need to throw out RBAC entirely—but they do need something more flexible. A proper implementation of ReBAC can be a way to preserve the basic RBAC structure while layering relationships, hierarchies, and context-aware rules on top.

The message from developers is clear: developers are looking for ways to extend the models they know, not replace them from scratch. Authorization systems that support composability—like combining RBAC with ReBAC, or layering ABAC conditions on top—are better aligned with how real applications evolve.

What’s Still Broken

Despite the growing interest in more advanced models, many teams are still stuck dealing with fragile, manual, or overly simplistic implementations. The survey revealed several areas where the developer experience around authorization is still falling short.

Policy Languages are Still Intimidating

• Over 52.6% of developers said they’ve never used any of the most popular policy languages - Rego, Cedar, or Alfa/XACML.

• When asked how approachable these languages are for newcomers, the average score was just 6.1 out of 10.

This isn't just a learning curve issue—it reflects a deeper gap in how policy tooling fits into modern development workflows. Most policy languages feel foreign to developers accustomed to working in their application code and infrastructure-as-code tooling.

Teams want the power of policy, but they don’t want to embed another language into their stack—or spend time learning a new language just to ship access control policies. Declarative SDKs, API-based configuration, integration with familiar tools like Terraform, or even no-code policy management UIs are often more appealing alternatives.

Real-time decision-making is still uncommon.

One of the more surprising results:

• 55% of respondents said they don’t evaluate authorization in real-time.

That means most teams make access decisions once and cache them, encode them in tokens, or just assume they won’t change. This might be fine for simple setups, but super risky in dynamic, multi-tenant, or collaborative environments.

Teams are either unaware of the value of just-in-time evaluation—or they’ve found it too difficult to implement with existing tools. Either way, the result is the same: fragile assumptions and static access models.

Fine-grained delegation is still rare.

• Only 24.9% of developers said they support self-assignment or delegation at a fine-grained level.
• The majority—41.1%—support it only at the role level, if at all.

This reflects how hard it still is to model authorization for authorization. Delegating access to resources, assigning roles within a scoped context, or letting users grant limited access to others—these are all common product requirements, but still difficult to build in practice.

Most systems aren’t designed to handle this kind of control natively, and doing it manually often means baking custom logic directly into the application.

What’s Changing

Even with the friction, developers are pushing their authorization systems forward—and the survey revealed a few clear shifts in mindset and priorities.

Fine-grained authorization is on the roadmap.

When asked about future plans:

• 53.1% of respondents said they plan to implement more fine-grained authorization within the next year.

That’s over half of all respondents actively planning to evolve their authorization systems—suggesting that many teams are outgrowing role-only models and beginning to tackle use cases like contextual access, approvals, and data-level security.

This shift reflects a broader realization: authorization isn’t just an infrastructure concern—it’s a product feature. It affects what users can see, do, and share - and that means it needs to evolve with the product itself.

Monetization is on the table—but not yet realized.

• Only 12.1% of developers say that authorization is part of a paid tier in their product.
• 65.9% said it’s included in all plans.

This doesn’t mean authorization isn’t valuable—it suggests it’s hard to charge for because it’s hard to build cleanly. Implementing premium features like secure collaboration, scoped access, or approval workflows often requires a level of flexibility that most in-house solutions can’t easily support.

There’s no doubt there’s an opportunity here - tools that externalize authorization and make fine-grained access control easier can unlock entirely new monetization strategies—especially for B2B products.

SaaS authorization tools are on the rise.

When asked directly:

• 75.7% of developers said they would consider using a SaaS authorization tool.

That’s a strong endorsement of the “don’t build it yourself” approach—especially in a domain as complex and risk-prone as authorization.

This growing interest reflects how developers are starting to treat authorization like other critical but externalized infrastructure: monitoring, CI/CD, authentication, and billing. The more customizable and developer-friendly these tools become, the less reason there is to reinvent them in-house.

Our Takeaways

The data tells a clear story: developers are deeply familiar with RBAC, still wrestling with complexity, and actively looking for more flexible, modern solutions.

Here’s what we’re taking away from this survey:

RBAC isn’t going anywhere—but it needs to evolve.

RBAC remains the dominant model, and for good reason. It’s simple, familiar, and easy to start with. But many developers are hitting its limits as their apps grow more complex. Instead of replacing RBAC, the more effective path is to extend it—with relationships (ReBAC) or conditions (ABAC) to make it more granular.

Fine-grained control is no longer optional.

More than half of developers are actively planning to adopt fine-grained authorization in the next year. The direction is clear: access control is becoming more dynamic, contextual, and user-driven. Systems that support this shift—without forcing teams to rewrite everything—will win.

Custom builds are still the norm, but the tide is turning.

Even though 62.2% of developers have built their own authorization system, three out of four would consider switching to a SaaS authorization tool. The appetite for externalizing authorization is growing—and so is the pressure to avoid reinventing the wheel.

Performance, delegation, and policy usability are still unsolved problems.

From slow authorization decisions to low adoption of real-time checks and policy languages, there’s a clear need for tools that offer both power and simplicity. Developers don’t want to fight their auth system—they want it to fit cleanly into their stack and scale with their product.

Final Thought

Authorization isn’t just a backend detail—it shapes the entire user experience. As expectations rise and architectures become more complex, it’s no surprise that more teams are rethinking how they model, implement, and scale access control.

The good news is that we’re entering an era where authorization is finally being treated as a first-class concern—and developers are ready for better tools to match.

If you’re looking to externalize your authorization without giving up flexibility, Permit.io lets you build RBAC, ReBAC, and ABAC-based permissions using SDKs, APIs, and Terraform - focus on your product, and never build permissions again.

Got questions? Want to learn more about authorization? Talk to us in our Slack community.