Most teams reach a point where authentication is handled. You've integrated Auth0 or Okta or Entra ID, your users can log in, SSO works, MFA is enforced. The identity layer is solid.
Then someone asks a question the IdP can't answer. Not "who is this person?" but "can this person do this specific thing, to this specific resource, right now?"
That's authorization. And it's where the gap starts to show.
What your identity provider actually covers
Entra, Okta, and similar platforms are built to solve authentication and basic identity management. They verify credentials, issue tokens, manage user directories, and handle federation across identity sources. They do this well.
Most of them also offer some authorization features. Typically that means role assignments attached to tokens, simple permission claims, and maybe a basic rules engine for access decisions. For straightforward use cases, a small set of static roles with a few hundred users, this can be enough.
The problem is that "enough" has a shelf life. As your application grows, as tenants multiply, as new services come online, the limitations become visible. And by the time they're visible, the cost of addressing them has compounded. Broken access control has been the number one vulnerability in the OWASP Top 10 since 2021. The gap between "we handle login" and "we control access properly" is where most of that risk lives.
Where the gap appears
The authorization capabilities most identity providers offer tend to break down along a few predictable lines.
Fine-grained, attribute-based decisions
Your IdP can tell you that someone has the "editor" role. It typically can't evaluate whether that editor should access a specific document based on its classification level, the editor's department, the time of day, and the document owner's relationship to the editor, all in a single check. These multi-attribute, contextual decisions are what real applications actually need, especially once you're past the early stages. NIST formalized this as Attribute Based Access Control in SP 800-162, establishing that access decisions should evaluate attributes of subject, object, action, and environment together.
Runtime evaluation against current state
Token-based authorization evaluates permissions at the moment the token is issued. But context changes between token issuance and the moment a user takes an action. A resource gets reclassified. A user changes departments. A tenant updates their configuration. If your access decisions are frozen in a token, they're stale.
Multi-service consistency
When authorization logic is embedded in each application or service, you end up with different teams implementing the same rules differently. One service checks roles from the JWT. Another queries a database. A third has permissions hardcoded in middleware. The result is drift, inconsistency, and a maintenance burden that grows with every service you add. As one commenter put it in a popular Hacker News discussion on distributed authorization, the industry has "a very frustratingly uneven set of solutions for authorization." Authorization policy should be defined once and reused everywhere, not copied, reimplemented, or reverse-engineered from code during an audit.
Tenant-aware policies
SaaS products almost always need different authorization rules per tenant. Enterprise customers expect to define custom roles, restrict actions, or scope visibility in ways that don't affect other tenants. Most IdPs don't have a concept of tenant-scoped authorization policies. So teams build it themselves, and it becomes the kind of technical debt that quietly consumes sprints for years. At Complex, managing edge case policies across a distributed architecture became untenable until they moved to externalized, centralized policy management that handled tenant-specific rules without duplicating infrastructure.
Auditable decision trails
Compliance frameworks like SOC 2, HIPAA, and PCI DSS don't just require access controls. They require evidence of how access decisions were made, which policy was in effect, what attributes were evaluated, and why a request was allowed or denied. Your IdP logs authentication events well. But a common audit finding is that companies log authentication events while missing authorization changes entirely. When an auditor asks "why did this user have access to this resource on this date?", you need to reconstruct the exact authorization decision, not just confirm they were logged in. With the average data breach costing $4.88 million in 2024 and $6.08 million in financial services (IBM), the evidence trail isn't optional.
Non-human identity governance
Microservices, AI agents, batch jobs, and third-party integrations all make requests which require authorization. They don't authenticate the way humans do, and the IdP-centric model wasn't built with them in mind. As organizations deploy more machine identities, the need for a purpose-built authorization layer that governs human and non-human actors consistently becomes hard to ignore.
Recognizing the decision point
None of this means you need to rip anything out. Your IdP remains the right system for managing identities and handling authentication. The question is whether you also need a dedicated authorization layer, separate from your IdP, that handles the access decision side.
A few signals that you're at that point.
1. Permission changes require code changes. If updating who can do what means editing application code, recompiling, testing, and redeploying, you've coupled authorization to your release cycle. That coupling gets expensive. At Human Managed, permission modifications used to require source code changes and full redeployment. After externalizing authorization, the same changes became a five-minute task.
2. Multiple services implement the same rules independently. If your checkout service, your admin dashboard, and your API gateway all have their own authorization implementations, you're maintaining N copies of logic that should live in one place.
3. Compliance prep is a scramble. If getting audit-ready means manually collecting evidence from multiple systems to demonstrate who had access to what, you don't have centralized authorization visibility.
4. Role explosion is making things harder, not easier. If your RBAC model has grown from a handful of roles to dozens or hundreds, and you're creating new roles to handle edge cases rather than solving the underlying model problem, the complexity will only accelerate.
5. Your team spends real engineering time on permissions. Authorization work is risky, detail-oriented, and rarely the kind of thing that excites engineers. An IDC study found that developers spend 19% of their weekly hours on security-related tasks, effectively costing organizations $28,000 per developer per year. If a meaningful chunk of that time is going to authorization logic, that's sprint capacity that isn't going to product features.
How to evaluate and shortlist authorization solutions
Once you've identified the gap, the next step is evaluating solutions with a structured approach rather than a feature-by-feature comparison. We published a detailed evaluation framework covering nine dimensions that enterprise teams should consider. Here are the ones that matter most when you're shortlisting.
| Dimension | Details |
|---|---|
| Policy model and expressiveness | Can the solution support RBAC, ABAC, and policy-based access control? Can you express conditions using attributes of the user, the resource, and the context of the request? Solutions that only support role-based checks will hit the same ceiling your IdP already hit. Look for a policy language that's readable by people outside engineering too. When auditors, product managers, or security leads need to understand the rules, a purpose-built policy language in YAML or a similar declarative format is more practical than a general-purpose programming language. |
| Integration with your identity stack and services | The authorization layer should consume identity context from your existing IdP without replacing it. It should work with your token format, your directory structure, your deployment model. Check for SDKs in the languages your team uses and APIs that fit your architecture, whether that's REST, gRPC, or both. An authorization solution that requires you to change how you handle identity is solving the wrong problem. |
| Deployment model and latency | Authorization is on the critical path of every request. Latency matters. A solution that adds tens of milliseconds per check will degrade user experience at scale. Look for architectures where the decision engine runs close to your application, ideally as a sidecar or within the same cluster, with in-memory evaluation and sub-millisecond response times. Stateless designs that allow horizontal scaling without shared state are easier to operate in production. |
| Multi-tenancy support | If you're building SaaS, evaluate how the solution handles per-tenant policy customization. Can you scope policies to individual tenants without duplicating your entire policy set? Can tenants have different roles, different rules, different access models without affecting each other? This is where many generic authorization tools fall short. |
| Audit logging and compliance readiness | Every authorization decision should be logged with enough context to reconstruct it later. That means the requesting principal, the action, the resource, the decision, and the policy version that was evaluated. Look for structured log formats that integrate with your SIEM, configurable retention, and the ability to correlate authorization decisions with application events. Cerbos Hub, for example, provides structured audit logs meeting SOC 2, ISO 27001, HIPAA, PCI DSS, and GDPR requirements, including a unique correlation ID (cerbosCallId) that links authorization decisions back to the originating application request. |
| Developer and admin experience | The learning curve matters. Solutions that require weeks of ramp-up before a developer can write a policy will face adoption resistance. Look for policy-as-code workflows with version control, testing and simulation tools, and a clear local development story. The ability for non-developers to understand and even modify policies, through a UI or readable policy files, reduces the engineering bottleneck over time. One enterprise team described their experience as taking a few days to understand the system and a couple of weeks to reach production. |
| Cost and build-vs-buy economics | One recurring pattern is teams underestimating the total cost of building authorization in-house. The initial implementation looks manageable. Then comes multi-tenancy, then audit requirements, then the second and third service, then policy versioning, then the engineer who built it leaves. A realistic build-vs-buy analysis should account for ongoing maintenance, not just initial development. One company estimated the lifetime cost of their in-house approach at seven figures. Another startup scoped the development cost alone at GBP 200,000 before exploring external options. |
Running a proof of concept
Before committing, run a focused POC against one real service. Not a demo app, an actual service in your stack with real users and real authorization requirements.
Define what success looks like up front. Can the solution model your existing permissions accurately? Does it handle the edge cases your team currently hardcodes around? What's the latency overhead under realistic load? Can a new developer write a policy without hand-holding?
Involve more than just the engineering team. Have your security lead review the audit output. Have a product manager read the policies. If the solution only makes sense to the person who configured it, adoption will stall.
The bigger picture
Authentication and authorization solve fundamentally different problems. Authentication has been successfully decoupled from applications for years, and the industry is better for it. Authorization is following the same trajectory.
There's a reason a Hacker News thread titled "Why Authorization Is Hard" drew over 300 upvotes and dozens of engineers sharing war stories. This is a problem most teams eventually hit, and the tooling to solve it properly is maturing. The OpenID Foundation's AuthZEN specification, ratified in January 2026, is formalizing the interface between enforcement points and decision points, much like OAuth/OIDC standardized authentication.
Your IdP handles identity. A dedicated authorization layer handles access decisions. Together they form a complete access control architecture. The teams that recognize this gap early, before compliance pressure or scale forces their hand, are the ones that avoid the painful migration later.
Try Cerbos to see how externalized authorization works in practice, or book a call to talk through your architecture with our team.
Go deeper: How to adopt externalized authorization (eBook) for a step-by-step playbook on decoupling authorization from application code.
FAQ
Tagged in
