Cerbos and APIM separate authorization from application code

At a glance

What this is: This is a walkthrough of separating authorization from application code by enforcing policy at the API gateway with Cerbos and Azure API Management.

Why it matters: It matters because IAM teams need consistent authorization decisions across services, and gateway enforcement changes where policy is governed, tested, and audited.

Context

Authorization is the decision about whether a request should be allowed, and this article argues for moving that decision out of backend code and into the API gateway. That matters for API authorization because duplicated rules in services create drift, while a central policy decision point can keep access logic consistent across endpoints.

The pattern here is not just gateway filtering. APIM validates tokens, passes request context to Cerbos, and Cerbos evaluates RBAC and ABAC rules against the request before the call reaches backend infrastructure. That makes the control plane for authorization easier to change, but also more dependent on token integrity, policy versioning, and audit visibility.

Key questions

Q: How should teams implement API authorization when it is separated from application code?

A: Teams should define policy in a central decision point, enforce it at the gateway, and keep the backend focused on business logic. The practical requirement is to version, test, and review policy changes with the same discipline used for application changes, because inconsistent policy becomes a cross-service access defect.

Q: Why do gateway policies still need strong JWT validation?

A: Gateway policies still depend on identity assertions, so token integrity, issuer trust, and claim parsing have to be correct before any access decision is made. If the gateway accepts weak or inconsistent tokens, the authorization layer inherits that weakness and can apply the wrong rule to the wrong principal.

Q: What breaks when authorization rules are scattered across gateways, services, and data systems?

A: When authorization rules are scattered, teams get inconsistent decisions, duplicated logic, and higher drift between intended and actual access. That creates blind spots during audits and makes it harder to revoke access quickly. Distributed enforcement still works best when the policy logic is centralized and versioned, so every decision reflects the same control intent.

Q: How should organisations choose between RBAC and ABAC for non-human identities?

A: Use RBAC for stable, repeatable access patterns and ABAC when access must change with context, resource type, or environment. For non-human identities, ABAC is usually better when workloads are ephemeral or shared across teams. The practical test is whether the access rule needs to follow the identity alone or the identity plus the conditions around it.

Technical breakdown

How gateway enforcement separates decisioning from application logic

Cerbos acts as the policy decision point, while APIM acts as the policy enforcement point. The gateway translates an HTTP request into a structured authorization check with principal, resource, and action, then blocks the call if the policy returns deny. That architecture lets access rules live outside service code, so teams can update policy without redeploying the backend. The important technical shift is that the application no longer interprets authorization itself; it becomes the protected resource behind a shared enforcement layer.

Practical implication: teams must treat gateway policy, not service code, as the authoritative authorization layer.

Why JWT validation happens twice in this design

The article describes two validation steps. APIM verifies the JWT signature and expiration before forwarding the request, then Cerbos verifies the token again when it extracts claims for ABAC evaluation. That may look redundant, but it separates transport trust from policy trust: the gateway rejects obviously invalid tokens, while the PDP still evaluates claim content against its own cryptographic source of truth. This reduces the chance that authorization depends on untrusted or partially processed token state.

Practical implication: duplicate token validation only works if both checks use trusted key material and consistent claim parsing.

RBAC and ABAC can coexist in one gateway policy

The sample policy uses RBAC for broad rules such as authenticated versus anonymous access, then ABAC for moderator-only deletion based on a JWT groups claim. That combination is common in API authorization because role alone is too coarse for some operations, while attribute-based logic can target specific business flows. The real governance issue is that mixed models increase policy complexity, so the policy set must be tested as code and versioned as a change-managed asset.

Practical implication: model coarse access with roles and narrow exceptions with attributes, then test both paths together.

NHI Mgmt Group analysis

Authorization policy has to be governed as infrastructure, not embedded logic. Once access rules move into a gateway and external policy engine, the control surface becomes versioned policy, not service code. That changes how teams review change, test enforcement, and prove consistency across APIs. The practical conclusion is that authorization becomes an independently managed identity control plane.

Gateway enforcement reduces code duplication, but it does not remove trust decisions. APIM still has to validate identity correctly, Cerbos still has to interpret claims correctly, and the policy model still has to encode the right resource boundaries. This is where IAM and API governance meet: the access model only stays reliable if the token, the request context, and the policy all agree. Practitioners should treat disagreement between those layers as a control defect, not an edge case.

Mixed RBAC and ABAC policy is a useful pattern for API governance, but it raises review complexity. Role checks handle broad entitlement, while claim-based conditions handle narrow privileged actions such as moderator deletion. That makes the named concept here a gateway authorization control plane: a central layer where request context, token claims, and policy versioning converge. The implication is that policy lifecycle discipline matters as much as policy design.

Centralised authorization can improve consistency across services, but it also concentrates failure impact. If the policy engine, token validation, or audit path is misconfigured, the failure affects every protected endpoint that depends on the gateway. That makes operational assurance, change control, and logging first-class governance requirements rather than implementation details. The practitioner takeaway is to manage the gateway as a shared access dependency, not a convenience wrapper around APIs.

What this signals

Gateway authorization control plane: moving authorization into the API gateway creates a central control layer that can be tested, versioned, and audited independently of service code. For IAM and API teams, the important change is that authorization drift now becomes a policy lifecycle problem instead of an application release problem.

This pattern also makes token trust and policy trust inseparable. If the gateway and policy engine do not agree on principal identity, claim content, or resource context, the access model becomes inconsistent in ways that are hard to detect through code review alone.

For practitioners

• Define authorization outside application code Move access rules into a shared policy layer so service teams stop reimplementing entitlement logic in each backend. Keep the policy source versioned, tested, and change-controlled like any other security control.
• Validate tokens at both control points Check JWT integrity and expiration at the gateway, then re-evaluate claims in the policy engine using trusted key material. Make sure the two layers agree on issuer, tenant, and claim shape before enforcing decisions.
• Model broad and narrow access separately Use roles for coarse access such as authenticated or anonymous, then reserve claim-based rules for privileged actions like moderation or deletion. That keeps the policy readable while preserving fine-grained control.
• Treat policy changes as code changes Unit test policy files, check deny and allow paths, and promote policy versions through the same review flow you use for application changes. Authorization drift is a change-management problem as much as a security one.

Key takeaways

• Separating authorization from service code can reduce duplication, but it shifts the governance burden to policy lifecycle, token trust, and gateway enforcement.
• The design described here combines gateway validation with policy engine evaluation, which creates a single access path that is easier to reason about but also easier to misconfigure broadly.
• IAM and API teams should manage the gateway policy layer as a shared security dependency, with testing and audit logging treated as part of the authorization model.

Key terms

• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• RBAC Policy: RBAC policy is the rule set that decides what a user, service, or other identity can do based on its assigned role. It maps roles to permissions, then applies those permissions consistently across systems, applications, and data. In practice, it reduces ad hoc access decisions and supports auditable, repeatable authorization.
• ABAC: Attribute-Based Access Control is a policy model that grants or denies access based on user attributes such as department, manager status, or employee type. It is useful when access needs to follow business rules, but those attributes must be accurate, current, and change-controlled or the policy can grant the wrong people access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.