Centralised authorization means decisions come from a common engine. Interoperable authorization means different enforcement points and compatible decision engines can communicate through a shared standard without custom integration. The first centralises authority, while the second makes that authority portable across systems.
How centralised and interoperable authorization differ in practice
Centralised authorization and interoperable authorization solve different problems. Centralised authorization concentrates the decision logic in one place, so policies, exceptions, and audit logic are managed consistently from a common control point. Interoperable authorization keeps those decisions portable across products and services, so one policy model can be enforced by multiple systems without building a bespoke integration for each one.
The practical difference is architectural. Centralisation gives you a single authority that can be simpler to govern and easier to standardise. Interoperability gives you a shared language between policy engines and enforcement points, which is more useful when applications, APIs, agents, or platforms must all ask for and honour decisions in a consistent way.
That distinction is why authorization models matter as much as the policy itself. If you are comparing models for a distributed environment, the relevant question is not only where the decision is made, but whether the decision can travel cleanly across system boundaries without losing context, policy intent, or enforcement consistency. The Authorisation Models Guide is useful here because it frames externalised authorisation, fine-grained policy, and compatible decision patterns together.
What changes when authorization becomes portable
Interoperable authorization becomes valuable when a single business policy must be enforced in more than one runtime, product, or trust boundary. Instead of hard-coding authorization logic into every application, you define the decision once and let different enforcement points query compatible policy components. That reduces duplication and makes access decisions more consistent across services.
Centralised authorization is still possible in that world, but it is usually narrower in scope. It works best when one platform or identity plane is authoritative for all decisions and the surrounding systems can reliably depend on it. Interoperability matters when the environment is heterogeneous, for example when multiple APIs, front ends, data services, or agent workflows need the same decision semantics but cannot all share one custom integration.
For teams building modern application estates, the strongest benefit of interoperability is not convenience alone. It is that portable authorization can preserve policy intent while allowing local enforcement. A compatible decision engine can evaluate the same rules for different systems, which makes it easier to keep least privilege aligned across a changing architecture. The same architectural logic appears in the IAM and IGA Basics guide, especially where it covers authorization models, access governance, and authentication versus authorization.
It also helps to think about who or what is being authorized. Interoperable patterns are especially relevant when the subject includes services, workloads, APIs, or AI agents that must request access in a standard way across systems. Where policy decisions need to be portable, the difference between a local access check and a shared authorization contract becomes operationally important. The AI Agent Authorisation Guide is a good example of how per-action decisions and delegated authority depend on that portability.
Where centralisation still wins, and where it becomes a constraint
Centralised authorization is strongest when governance is the priority. It gives security teams one place to review policy, one place to tune exceptions, and one place to measure decision outcomes. That can reduce policy drift and simplify audit evidence, especially in environments that have not yet standardised their identity or access model.
The trade-off is that centralisation can become a bottleneck if every application must integrate directly with one bespoke service. It can also create a control-plane dependency if the entire estate must reach that one decision source at runtime. In practice, centralised authorization works best when the authority is common but the enforcement remains distributed enough to avoid a fragile single point of failure.
Interoperable authorization addresses that constraint by separating policy semantics from implementation detail. The shared standard is the important part: it lets multiple enforcement points understand the same authorization language, rather than forcing every product to speak a different one. That is why RFC 6749: The OAuth 2.0 Authorization Framework matters as a baseline reference, even though many interoperable systems go beyond OAuth alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Directly governs enforcing authorization decisions at enforcement points. |
| IA-9 — Service Identification and Authentication | Covers machine-to-machine authorization paths where interoperable decisions depend on trusted service identities. | |
| AC-6 — Least Privilege | Centralised and interoperable models both need least-privilege decisioning to limit access. | |
| Recommendation — Apply AC-3 to enforce policy decisions consistently at each access point. Apply IA-9 to authenticate services that participate in portable authorization flows. Apply AC-6 to keep each subject limited to the minimum required access. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Relevant because inconsistent authorization across APIs is a core failure mode when enforcement is not portable. |
| Recommendation — Use API5 to test that each API enforces the intended authorization decision. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directly supports choosing and governing an organization-wide access control model. |
| Recommendation — Define and maintain a consistent access control policy across systems. | ||
Practitioner Guidance
What to verify: Check whether your current estate needs one authority for governance, or many compatible enforcement points for portability. If one system owns both the policy and every decision path, centralisation may be enough; if not, the authorization model should be designed for interoperability from the start.
Decision rule: Use centralised authorization when the main goal is uniform policy control and simplified review. Use interoperable authorization when the main goal is to avoid custom integrations and keep the same policy semantics usable across heterogeneous systems.
Common mistake: Treating interoperability as a replacement for governance. A shared standard makes integration easier, but it does not by itself guarantee good policy design, least privilege, or consistent enforcement.
Practitioner takeaway: The right choice depends on whether you are optimising for a single source of authority or for portable enforcement across many systems, and most mature environments eventually need both.
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?