The identity industry solved authentication in public and authorization in private. Over the last fifteen years, the question of who you are became a matter of shared standards: SAML, OAuth 2.0, OpenID Connect, and now passkeys are protocols any two systems can speak to one another. The question of what you are allowed to do never received that treatment. Authorization stayed inside the application, written by application developers, expressed in whatever logic the codebase happened to use. That asymmetry is now the most expensive unsolved problem in enterprise identity, and for the first time it is being addressed as a standards problem rather than a coding problem.
The authorization every enterprise built, and why it strained
Most large organizations authorize the way they did in 2010. Access is governed by roles, and roles are checked in code. A role-based model is easy to reason about when there are a dozen roles and one application. It stops being easy when there are thousands of roles across hundreds of applications, each with its own interpretation of what a role means.
The failure mode has a name that IAM teams use without needing to explain it: role explosion. Every access requirement that does not fit an existing role produces a new role, and roles accumulate faster than anyone retires them. The result is an authorization estate that no single person understands, where proving who can access what for an auditor becomes a multi-week archaeology project. Worse, the logic lives in each application, which means the same policy, "contractors cannot export customer records," is implemented separately, and slightly differently, in every system that touches customer records. There is no single place to ask "who can do this," because the answer is scattered across dozens of codebases.
From roles to relationships and attributes
The response has been to move beyond roles as the only primitive. Two models matter here.
Attribute-based access control evaluates decisions against attributes of the user, the resource, and the context rather than a static role. NIST formalized the approach in SP 800-162, which describes authorization as a policy evaluated over attributes such as department, clearance, resource sensitivity, time of day, and device posture. ABAC expresses "a manager in the finance department can approve expenses under 10,000 during business hours" as a policy rather than as a role that has to be minted and assigned by hand.
Relationship-based access control takes a different angle. It models authorization as a graph of relationships between subjects and objects, and answers questions by traversing that graph. The canonical implementation is Zanzibar, the global authorization system Google described in 2019, which resolves billions of access checks by asking whether a relationship path exists between a user and a resource. The document-sharing model everyone recognizes from consumer file storage, where this user is an editor of this folder, that folder contains this file, therefore this user can edit this file, is a relationship model. Zanzibar showed it could run at a scale no one had previously attempted for authorization.
Externalizing the decision
The deeper shift is architectural, and it predates both models. The older XACML standard split authorization into a policy decision point that evaluates policy and a policy enforcement point that asks the decision point for a verdict and then enforces it. XACML itself, weighed down by XML, never achieved broad adoption, but the split it described is the foundation of modern externalized authorization: applications stop deciding for themselves and instead call out to a dedicated authorization service.
That is now a working pattern rather than an aspiration. Open Policy Agent, a graduated project of the Cloud Native Computing Foundation, evaluates policy written in its Rego language and is widely deployed as a decision point for infrastructure and API authorization. OpenFGA, a CNCF project that grew out of the identity vendor world, implements the Zanzibar relationship model as reusable infrastructure. Amazon's Cedar policy language, which powers its Verified Permissions service, brings a purpose-built and analyzable syntax to application authorization. The common thread is that authorization policy becomes a managed artifact, versioned, tested, and auditable as code, held outside the applications it governs.
The standard authorization was missing
Externalizing the decision solves the sprawl but creates a new gap. If every authorization service exposes a different interface, an enterprise that adopts one has locked its applications to that vendor's protocol as surely as it was once locked to hard-coded roles. Authentication avoided this fate because the industry agreed on how a relying party talks to an identity provider. Authorization had no equivalent.
The OpenID Foundation's AuthZEN working group is building that missing piece. Its Authorization API defines a standard request and response for the moment an enforcement point asks a decision point whether a given subject may take a given action on a given resource. The goal is interoperability at the decision boundary: an application should be able to call any conformant authorization service without rewriting its enforcement logic, and organizations should be able to change decision engines without changing every application. AuthZEN has run public interoperability demonstrations with multiple vendors implementing the same specification, the same milestone OpenID Connect passed on its way to becoming the default for federated login.
What identity teams should take from this
The practical message is not that roles are obsolete. Role-based access remains the right tool for coarse, stable assignments, and most environments will run a hybrid model for years. The message is that authorization is becoming a first-class identity discipline with its own architecture, its own policy artifacts, and now its own interoperability standard, rather than an implementation detail left to each application team.
This matters most for organizations pursuing zero trust, where authorization has to be a continuous decision rather than a one-time grant at login. Continuous evaluation is only tractable if the decision lives in one place that can be queried, updated, and reasoned about, instead of being frozen into the token scopes issued at authentication time. The scope and claims model that OAuth 2.0 provides is a coarse authorization layer, useful for expressing broad grants but not for deciding whether this specific user may edit this specific record right now. Fine-grained, externalized authorization is what fills that gap.
No one has produced a complete answer yet. Migrating years of embedded authorization logic into an external policy engine is slow, unglamorous work, and the tooling for discovering what an application's existing rules actually are remains immature. But the direction is set. Authentication became a shared language a decade ago, and the identity teams that watched it happen are watching the same pattern repeat one layer up. The question of what you are allowed to do is finally being answered in the open.