What is the difference between gateway authorization and centralized authorization?

Gateway authorization decides access at the edge and often encodes the result into a token, while centralized authorization keeps the policy decision in a dedicated service that domain services query at runtime. Gateway models are simpler for coarse access, but centralized models handle fine-grained permissions more consistently across service boundaries.

Why This Matters for Security Teams

Gateway authorization and centralized authorization are both answers to the same problem, but they shift risk to different parts of the system. A gateway can make the access decision early, which is useful for coarse filtering and traffic reduction. Centralized authorization keeps the policy brain in one place, which usually improves consistency, auditability, and change control. That distinction matters because non-human identities already create scale and visibility problems; NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts in its Ultimate Guide to NHIs — What are Non-Human Identities.

For security teams, the real issue is not where the decision happens, but whether the decision can stay aligned with policy as identities, services, and secrets change over time. A gateway that embeds authorization into a token can be efficient, yet it may go stale if the token outlives the policy that created it. A centralized model can adapt faster, but it depends on strong service-to-service trust and resilient policy infrastructure. This is why controls in NIST SP 800-53 Rev 5 Security and Privacy Controls continue to emphasise access enforcement, accountability, and monitoring rather than a single architectural pattern. In practice, many security teams encounter authorization drift only after service sprawl and stale tokens have already widened access.

How It Works in Practice

Gateway authorization typically sits at the ingress layer, where it can inspect the request, apply policy, and either allow, deny, or attach claims that downstream services trust. That makes it effective for basic boundary enforcement, especially when the same decision applies to many requests. Centralized authorization, by contrast, pushes the policy decision into a dedicated service or policy engine that domain services call at runtime. That model is more flexible because the decision can use current context, such as user role, NHI attributes, request purpose, data sensitivity, and environment state.

In mature environments, the decision usually hinges on whether the application needs consistent enforcement across many services or only a coarse edge check. Common implementation patterns include:

• Gateway checks for broad allow or deny conditions before traffic enters the mesh or application tier.
• Central policy engines evaluate fine-grained rules at request time, often via policy-as-code.
• Service credentials and tokens are kept short-lived so policy changes take effect quickly.
• Domain services still validate identity and scope even when a gateway has already approved the request.

This difference is especially relevant to NHI governance because service accounts, API keys, and machine tokens are often overprivileged and long-lived. The Ultimate Guide to NHIs — What are Non-Human Identities highlights how widespread that exposure is, and NIST guidance on access control reinforces the need for consistent enforcement and review. Centralized authorization is usually a better fit when teams need a single source of truth for permissions across multiple services, while gateway authorization is better suited to broad perimeter-style checks. These controls tend to break down when applications cache decisions too long because policy and token state diverge.

Common Variations and Edge Cases

Tighter centralized authorization often increases latency and operational overhead, requiring organisations to balance consistency against availability and complexity. That tradeoff is why many systems use a hybrid model: the gateway performs an initial coarse check, while the application or a policy service performs the final decision for sensitive actions. Current guidance suggests this layered approach is safer than relying on the gateway alone, but there is no universal standard for where the split must occur.

Edge cases usually appear when a gateway token is treated as proof of broad entitlement instead of proof of an initial checkpoint. That becomes risky when service boundaries differ, when one request fans out into several downstream calls, or when secrets and roles change faster than token expiry. In high-change environments, centralized authorization also needs careful caching, fallback logic, and strong service identity so the policy service does not become a single point of failure. For teams building more mature NHI controls, the key reference point is the lifecycle and visibility problem described in Ultimate Guide to NHIs — What are Non-Human Identities. In practice, the gateway-first model tends to fail when microservices make independent downstream decisions after the initial token has already been overtrusted.

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?