Externalized authorization is becoming essential beyond IdPs

At a glance

What this is: This is an analysis of why identity providers handle authentication better than authorization, and why externalized policy is becoming necessary for finer-grained, auditable access control.

Why it matters: It matters because IAM teams must govern not only who authenticates, but also how human and non-human actors are authorised at runtime across applications, tenants, and compliance regimes.

By the numbers:

• Broken access control has been the number one vulnerability in the OWASP Top 10 since 2021.
• The average data breach cost $4.88 million in 2024.
• 19% of their weekly hours on security-related tasks., ty-related tasks.

👉 Read Cerbos' analysis of why externalized authorization matters beyond IdPs

Context

Most identity providers solve authentication, federation, and basic role assignment well, but they were not designed to carry the full weight of authorization decisions in complex applications. Once access depends on resource attributes, request context, tenant scope, and changing state, static token claims and simple role checks start to fall behind the business problem.

For IAM teams, the issue is not whether the IdP is working. The issue is whether authorization is now a separate governance layer that needs its own policy model, audit trail, and operational ownership. That distinction matters across human access, service accounts, and AI-driven request patterns, especially where policy drift can become a control failure.

Key questions

Q: How should security teams implement externalized authorization in existing applications?

A: Start with one application that already has visible permission complexity, then move its access rules into a central policy layer. Keep authentication in the IdP and pass identity context into the decision service. The goal is not a rewrite, but a clean separation between who the user is and whether that user can act on a specific resource in the current context.

Q: When does role-based access control stop being enough for IAM governance?

A: RBAC stops being enough when access depends on resource attributes, tenant boundaries, environment, or time, rather than a small set of static roles. At that point, teams need attribute-aware or policy-based decisions. If new edge cases keep forcing new roles, the model has already exceeded the usefulness of simple role assignment.

Q: What do teams get wrong about authorization logging and audits?

A: Teams often log authentication events and assume that is sufficient evidence. It is not. Auditors need to see which policy was applied, which attributes were evaluated, and why the allow or deny decision happened. Without that, access questions become forensic exercises instead of routine governance checks.

Q: How do I know if authorization should be separated from the IdP?

A: If permission changes require code edits, multiple services implement the same rules differently, or audit preparation depends on manual evidence gathering, authorization should be externalized. Those are signals that the IdP is doing its job for identity, but the access decision layer has outgrown it.

Technical breakdown

Why IdP-based roles hit a ceiling

Identity providers are usually built to assert identity and issue claims, not to evaluate rich access context at request time. Role-based checks work until the decision depends on multiple attributes such as resource classification, ownership, department, environment, and time. At that point, the logic becomes too conditional for static claims in a token. The access model needs a decision layer that can evaluate subject, object, action, and environment together, rather than treating authorization as a fixed property of the user.

Practical implication: move complex access decisions out of token claims and into a policy layer that can evaluate context at runtime.

Why distributed authorization drifts across services

When each service embeds its own authorization logic, the same business rule gets implemented multiple times in different ways. One service checks a JWT role, another queries a database, and a third hardcodes permissions in middleware. That creates drift, inconsistent outcomes, and expensive audit reconstruction. Centralized policy avoids the hidden problem of every team reinterpreting access rules slightly differently, which is how control gaps become operational debt.

Practical implication: standardise policy evaluation so one rule set governs multiple services instead of duplicating logic in application code.

Tenant-aware policy and audit trails

SaaS environments commonly need per-tenant access rules, custom roles, and resource scoping that do not spill across customers. Generic IdP controls rarely model that cleanly, so teams build bespoke authorization logic that is hard to maintain and harder to evidence. Compliance also depends on reconstructing the exact decision, including which policy version ran and which attributes were evaluated. Without that trace, authentication logs alone cannot explain why access was allowed or denied.

Practical implication: require tenant-scoped policies and decision logs that can be correlated back to the originating request.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization debt is the hidden governance problem behind mature identity stacks. Teams often assume that once SSO and MFA are in place, access governance is largely solved. That assumption fails because authorization is not a login problem, it is a continuous decision problem. The implication is that identity programmes need a separate control plane for access decisions, not just stronger authentication plumbing.

Broken access control is where authentication-centric IAM programmes become brittle. The article correctly points to the gap between identity proofing and decision logic, and that gap is already visible in the OWASP Top 10. Static roles, token claims, and embedded permission checks are manageable at small scale, but they do not provide the expressive power needed for contextual enforcement. Practitioners should treat authorization as a distinct control domain with its own ownership and evidence model.

Multi-service authorization consistency is an architecture issue, not just a developer convenience. Once each service interprets permissions independently, policy drift becomes inevitable and auditability fragments. That is true for human users today and becomes even more consequential when service accounts and automation start calling the same APIs at machine speed. Practitioners should align service-level enforcement to a central policy source before the estate hardens around inconsistent rules.

Tenant-aware authorization is the named concept this pattern exposes. Multi-tenant products need access rules that vary by customer, resource, and context without duplicating policy logic or leaking one tenant's permissions into another's boundary. That is more than an implementation detail, because tenant-aware authorization determines whether scaling the application also scales the governance model. Practitioners should treat tenant scoping as a first-class design requirement, not a post-launch fix.

Audit-ready authorization is now part of identity governance, not a compliance afterthought. A log showing that someone authenticated is not evidence of why they were allowed to access a specific resource at a specific moment. The field needs decision trails, policy versioning, and correlation back to the originating request. Practitioners should verify that their access model can answer auditor questions without manual reconstruction.

From our research:

• 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.
• Ultimate Guide to NHIs also shows that 92% of organisations expose NHIs to third parties, which is why delegated access needs tighter governance than login alone.

What this signals

Decision-layer governance will become a mainstream IAM requirement: organisations that keep treating authorization as application code will keep paying for drift, audit friction, and slow change. The practical shift is toward a policy plane that can serve human users, service accounts, and automated requestors without duplicating rules in every service.

Policy drift is the real scaling tax: once teams have more than one enforcement point, the question is no longer whether authorization exists, but whether it remains consistent enough to trust. That pushes IAM programmes toward central policy management, decision logging, and explicit ownership boundaries across engineering and security.

As applications add more tenants and machine-triggered requests, the access model has to become more explicit about context, scope, and evidence. Teams that do this early will reduce the gap between what an application can technically do and what the governance model can actually explain.

For practitioners

• Separate authentication from authorization ownership Assign a distinct control owner for access decisions, policy changes, and audit evidence. Authentication teams can continue to manage login and federation while platform or security teams own policy logic, approval boundaries, and decision logging.
• Externalise context-dependent access rules Move rules that depend on resource sensitivity, tenant scope, time, or request context into a central policy layer. Keep application code focused on enforcement calls rather than reimplementing business permissions in every service.
• Require decision trails for every deny and allow Log the principal, action, resource, policy version, and evaluated attributes for each authorization decision. Make those logs searchable in your SIEM so auditors and security reviewers can reconstruct the access path without manual guesswork.
• Test authorization against a real service before rollout Run a proof of concept against one live application with real permission edge cases, then validate latency, developer usability, and audit output. Use that exercise to expose whether your current model can survive production scale.

Key takeaways

• Authentication and authorization are separate control problems, and treating them as one leaves the access decision layer under-governed.
• The evidence in this article points to a familiar scaling pattern: static roles, embedded checks, and token claims become brittle as applications, tenants, and audit demands grow.
• Practitioners should externalize contextual access decisions before policy drift, compliance pressure, and service sprawl make the migration harder.

Key terms

• Externalized Authorization: Externalized authorization separates access decisions from the application and the identity provider. The system still authenticates users, but a dedicated policy layer decides whether a specific action is allowed on a specific resource in the current context. That separation improves consistency, auditability, and change management.
• Attribute-Based Access Control: Attribute-Based Access Control is a decision model that evaluates attributes of the subject, resource, action, and environment before granting access. It is more flexible than static role checks because it can reflect context such as tenant, classification, ownership, or time of request.
• Policy Drift: Policy drift occurs when the same access rule is implemented differently across applications, services, or teams. The resulting behaviour may look correct in isolation but becomes inconsistent at scale. In practice, drift creates hidden exceptions, audit gaps, and security outcomes that no one can fully explain.
• Tenant-Scoped Policy: Tenant-scoped policy restricts authorization rules to a specific customer boundary or organisation context. It allows one SaaS platform to support different roles, permissions, and resource visibility per tenant without exposing those rules to other tenants or duplicating the entire policy model.

Deepen your knowledge

Authorization governance and policy-based access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment is moving from static roles toward runtime decisions, that course gives you a structured way to frame the change.

This post draws on content published by Cerbos: Why your IdP isn't enough for authorization. Read the original.