API Gateway

An API gateway sits in front of services and handles shared request processing. Azure API Management places it alongside a management plane for provider configuration and a developer portal for consumer discovery and subscription.

Microsoft documents routing, credential verification, usage limits, optional transformations and caching, and telemetry as gateway capabilities. Each needs a policy and an operational owner.

Uniform edge enforcement is a responsibility boundary, not a technical inability to read application data. A gateway can query a backend or external policy decision service. The resulting latency, availability, freshness, and failure handling must then be designed as part of the request path.

Which questions belong where

RFC 6750 recommends 403 for insufficient scope. A general scope such as invoices:read does not establish permission for a specific invoice; richer grants can express targets and actions, as RFC 9396 describes. Neither the error vocabulary nor the grant format determines where every decision must execute. Current ownership and business-state checks remain separate obligations.

Microsoft’s OWASP guidance prefers object authorization in the backend API, while documenting custom gateway policies and external lookups as fallbacks. The preference has practical reasons: the backend can use current data, cover paths that bypass the gateway, and couple a state-dependent check with the change it authorizes.

An implicit division can leave services trusting checks the gateway never made, or leave gateway policies carrying independently maintained domain rules. These risks depend on ownership, review, and testing. Policy configuration can receive the same engineering controls as service code.

Why policies drift

Azure API Management policies apply sequential processing at global, workspace, product, API, and operation scopes. Review the effective combination and keep changes under version control; being configuration does not make a change harmless.

Three design choices deserve explicit boundaries.

• Copied business rules. Independently implementing pricing or eligibility at the edge creates a possible second authority. Delegating to an owned decision service can preserve one rule implementation; the gateway still needs a contract for latency, availability, freshness, and enforcement.
• Response transformation. An owned compatibility adapter or consumer facade can legitimately reshape application data beyond protocol conversion. Test the contract and preserve domain meaning. Undocumented transformations create the maintenance risk.
• Orchestration nobody owns. Merging several backend calls at the gateway is a recognized pattern — aggregation at the edge saves a chatty client round trips — so the problem is not the placement but the absence of what a service would have had: a name, an owning team, tests, its own deployment. Without those it is logic in the request path of everything else on that gateway, and nobody’s job. Move it into a service when its resource use or failure behavior should not be shared with other traffic, or when it needs to ship independently; and treat long-running business orchestration, which needs durable state, as a service from the start rather than a policy.

None of which means policy cannot be engineered properly. It is text, so it belongs in version control and in a pipeline, and vendors ship tooling for testing it — Azure’s policy toolkit lets policies be authored as code alongside a testing package, so policy expressions are covered by ordinary unit tests. Treat the three questions as the test: who owns this policy, where is it reviewed, and what fails if it is wrong. Where those have answers, a policy is a legitimate home for edge concerns; where they do not, that is the condition to fix rather than a property of gateways.

Gateway telemetry records requests and credentials and supplies evidence for an audit log. Correlate it with backend authorization and observed business outcomes before claiming who performed a business action or whether it completed. Shared credentials and missing observations limit that conclusion.

The gap worth checking

A gateway’s guarantees hold only for traffic that passes through it. If a service can also be reached directly — from inside the network, through a port-forward, by another service — then a caller who never presented a credential gets whatever the service grants to callers it assumes were checked. Network controls narrow that path; the service verifying the caller identity itself is what closes it.

So the useful summary is a division of labor rather than a delegation. The gateway does the uniform work once, correctly, for everyone: authentication using the configured token profile and any required sender proof, grant enforcement, quotas and throttling, and observability. Each service still validates its own inputs and performs its own authorization against the data it owns, as though no gateway existed. How the two halves are agreed between a platform team and service teams is worked through in API Management and Delivering a Service.

References

• Microsoft Learn, Azure API Management: Overview and key concepts
• RFC 6750, Bearer Token Usage, Error Codes
• Microsoft Learn, Gateway Aggregation pattern
• Microsoft Learn, Recommendations to mitigate OWASP API Security Top 10 threats using API Management
• Azure API Management Policy Toolkit
• RFC 9396, OAuth 2.0 Rich Authorization Requests
• RFC 9068, JWT Profile for OAuth 2.0 Access Tokens
• RFC 9449, DPoP