Notifications
Clear all
Topic starter
10/06/2026 11:34 pm
TL;DR: Moving authorization out of application code can be achieved by pairing a policy decision point with Azure API Management, so gateway policy can allow, deny, and inspect JWT claims before requests reach backend services, according to Cerbos. The governance lesson is that centralised decisioning helps consistency, but only if policy versioning, token validation, and audit logging are treated as part of the access model.
NHIMG editorial — based on content published by Cerbos: decoupling authorization from application code with Cerbos and Azure API Management
Questions worth separating out
Q: How should security teams implement gateway-based authorization for APIs?
A: Security teams should place the enforcement decision at the gateway, translate each request into a stable principal and resource model, and keep policy logic in a separate decision engine.
Q: When does role-based access control need attribute-based rules at the API edge?
A: Role-based control is usually enough for broad access patterns such as read-only or authenticated access.
Q: How do you know whether gateway authorization policies are actually working?
A: You know they are working when policy tests cover both allowed and denied scenarios, decision logs are captured, and changes can be released without breaking expected access.
Practitioner guidance
- Map the gateway identity model carefully Translate each request into a stable principal, resource, and action before the policy engine evaluates it.
- Separate validation from authorization decisions Use the gateway to verify token signature and expiry, then send the trusted identity context to the policy decision point for authorization.
- Test policy paths like code paths Build policy tests for authenticated, anonymous, and claim-based cases, including deny scenarios.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Complete APIM inbound policy example showing how HTTP requests are translated into Cerbos check requests
- Full Cerbos YAML policy files for read, search, review submission, and moderator deletion rules
- Container Apps deployment manifest, including policy storage, scaling, and HTTPS ingress settings
- Policy test fixture structure for eleven access scenarios, useful for implementation and validation
👉 Read Cerbos' guide to gateway-based authorization with APIM and Cerbos →
API gateway authorization with Cerbos and APIM: what changes?
Explore further
12/06/2026 5:49 am
Centralised authorization only works when identity context is faithfully translated at the gateway. This pattern makes APIM the enforcement layer, but the real control plane is the mapping from HTTP request to principal, resource, and action. If that mapping is incomplete or inconsistent, policy correctness is lost even when the policy engine itself is sound. The practitioner conclusion is that gateway-based authorization is a data quality problem as much as a policy problem.
A few things that frame the scale:
- Cerbos policy evaluation typically completes in under 1ms, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records.
A question worth separating out:
Q: What is the difference between enforcing authorization in the gateway and in application code?
A: Gateway enforcement centralises access decisions before requests reach backend services, while application-code enforcement spreads those decisions across individual services. The gateway model reduces duplication and creates a single policy lifecycle. Application-code enforcement can still be useful for local business rules, but it is a weaker choice for shared authorization policy.
👉 Read our full editorial: Cerbos and APIM separate authorization from application code
