API Management and Service Delivery

Consider a hypothetical failure. A platform team puts a gateway in front of several services and treats authentication and authorization as centrally solved. A penetration test then finds that an authenticated caller can read another customer’s invoice by changing an identifier in the URL. The gateway checked the credential, but neither it nor the service checked ownership of the requested invoice.

That gap is the subject of this article. A gateway provides uniform enforcement and can also consult application data or an external authorization service. Its responsibilities still need to be explicit: otherwise each side assumes the other checked access. The following sections explain that division, quotas and rate limits, and the support needed to deliver an API that other teams can adopt.

What the gateway actually does

Azure API Management separates three roles: the API gateway handles the request path, the management plane holds provider configuration, and the developer portal supports discovery and subscription. Keeping those roles separate makes ownership easier to assign.

Microsoft documents gateway capabilities including routing, credential verification, usage limits, transformations, optional caching, and telemetry. These are capabilities to configure and operate; their presence does not establish that every request has received the authorization checks its data requires.

Uniform request handling is a useful default responsibility for the gateway, not a limit on what it can know. A policy can fetch data or delegate a decision. Doing so adds dependencies whose latency, availability, freshness, and failure handling become part of the request path.

Question	Who can answer it
Is this credential valid for this API?	Gateway. Validate the configured token profile, trusted issuer and keys, permitted algorithms, required claims, and any sender proof. Bearer validity alone does not prove possession of a client private key.
Is this caller allowed to use this operation at all?	Gateway, from the token’s scopes or the product subscription
Has this caller exceeded what they may consume?	Gateway. It keeps the counters
Is the request well formed?	Gateway for schema and size; the service for anything semantic
May this caller see this record?	The service, by default and by preference. It can check ownership and current state. A gateway may enforce a decision from an external policy service without copying its rules; the contract must still address freshness, outages, and bypass paths.
Is this operation valid in the current business state?	The service. Whether an order can still be canceled depends on state the gateway would have to fetch, and checking it anywhere but where the change commits leaves a race

An implicit division can fail in two directions. Services can omit object authorization because they assume the gateway performed it. Gateway policies can also accumulate independently maintained domain rules. The second risk arises when policy ownership, review, and tests are missing; maturity of the installation does not by itself establish how often that happens.

The rule that holds: the gateway is a policy enforcement point for things decidable at the edge, and every service still validates its own inputs and authorizes its own data access. That is not redundant work; the two are answering different questions.

Tokens: what the edge can check

An access token is a credential representing an authorization granted to a client. In the OAuth model, the authorization server issues it, the client presents it, and the resource server checks whether the requested access is permitted. It avoids sending the underlying login credentials with every API request.

The following five checks are an overview for a chosen signed bearer-token profile, not a complete validator for every access token. Use a maintained validation library configured for the expected token kind and issuer, trusted keys, application-permitted algorithms, and all required claims. For the RFC 9068 JWT access-token profile, also validate typ as at+jwt or application/at+jwt; that exact type rule is not universal to all JWT schemes.

• Signature, using keys trusted for the configured issuer and an explicitly permitted algorithm. Do not let untrusted token contents choose the trust policy.
• Issuer, so a token minted by a different authority is rejected rather than trusted for looking similar.
• Audience. Reject tokens intended for another resource server; sharing an issuer does not make all tokens interchangeable.
• Expiry, with whatever clock tolerance you have decided and written down.
• Scope or grant, interpreted according to the API contract. A general scope such as invoices:read grants a class of operation; a richer grant can identify specific targets.

RFC 6750 distinguishes invalid_token, for which the resource server SHOULD respond with 401, from insufficient_scope, for which it SHOULD respond with 403 and MAY identify the necessary scope. The client MAY obtain a new token and retry an invalid-token request if its refresh or grant remains authorized. Bound that recovery and stop on persistent failure; fetching the same privileges again will not fix insufficient permission.

These Bearer error codes do not define the complete object-authorization model. A general scope does not decide ownership of a specific invoice, while RFC 9396 supports richer grants for specific targets and actions. Current row state can still require a separate check. The distinction between authentication and authorization remains: accepting a credential does not authorize every object named in a request.

Grant scopes per client and keep them narrow — the same least privilege reasoning as anywhere, and a token carrying every scope because it was easier is a credential whose theft is maximally useful.

Choose validation by token profile. An opaque reference can be checked through introspection or the provider’s validation mechanism rather than local signature verification. Sender-constrained schemes additionally require the applicable proof and token-to-key binding checks; a valid JWT signature alone is insufficient. RFC 9449 specifies those requirements for DPoP.

For the RFC 6750 Bearer flow, a request missing authentication information requires a WWW-Authenticate challenge using Bearer; the server SHOULD NOT add an error code or other error information in that case. Its example is 401 Unauthorized with WWW-Authenticate: Bearer realm="example". Keep that rule scoped to this scheme: RFC 9449 uses a DPoP challenge for DPoP authentication.

Quotas and rate limits are two different things

A useful operating distinction is allocation versus protection. The table illustrates one division of responsibility, not universal definitions: quotas can enforce internal fairness, commercial plans can impose per-second limits, and the same mechanism can serve both purposes.

	Quota	Protective rate limit
Purpose	Defines what a consumer bought or was allocated	Keeps the service standing
Set by	The product, allocation policy, or commercial agreement	Engineering, from measured capacity
Period	For example, a day or month; a lifetime allocation is also possible	For example, a second or minute; the window follows the protection goal
When exceeded	Wait for renewal, reduce or correct usage, or seek an approved allocation change; waiting does not renew a lifetime quota	Reduce offered load and investigate sustained or unexpected saturation
Who should be told	The consumer, with usage and renewal information	Operators when saturation is sustained, unexpected, or affects service objectives; normal enforcement need not page anyone

Both controls can implement throttling. RFC 6585 defines 429 for a caller sending too many requests in a period. General temporary overload can instead use 503 under RFC 9110; severe attack conditions may require dropping connections. A 429 response SHOULD explain the condition and MAY include Retry-After. Supply a meaningful wait hint when it can be computed, and define bounded fallback Retry-After and backoff behavior for clients when it is absent.

Azure API Management distinguishes its policies: rate-limit returns 429 when exceeded, while quota returns 403 with a Retry-After interval. Document that mapping so clients do not misclassify an allowance breach as an authentication problem. The response policy and the allocation’s renewal rules together determine what a consumer should do next.

RFC 6585 leaves caller identification and request counting to the implementation. Specify both, along with the scope and precision of enforcement.

• What identifies the caller. A subscription key, a client identity from the token, a source address. An address groups unrelated callers behind one office network and splits one caller across many containers, so it is the weakest of the three.
• How requests are counted. A fixed window can admit one full allowance just before a boundary and another just after it. An exact sliding-window counter limits any rolling interval. A token bucket has a different contract: burst capacity B plus replenishment at rate r. A full 100-request bucket replenished at 100 per minute can admit an initial 100 plus replenished requests during that minute; it does not guarantee at most 100 in every rolling minute. This is an illustrative API counting model using the burst-and-rate distinction also described for network traffic in RFC 2697.
• Where counts apply. Azure API Management documents independent gateway counts, including regional gateways, and approximate distributed enforcement. Three reachable regions each configured for 100 could therefore expose roughly three allowances if no aggregate limit intervenes; 300 is an illustration, not an exact ceiling. A strict global admission cap needs coordination or allocated budgets with defined failure behavior. Accurate billing is a separate metering contract: distributed records can be deduplicated, recovered, and reconciled later. One logical accounting contract does not require one physical store.
• What counts as one request. A call count still limits invocation volume, but it may poorly approximate load when one call can request ten thousand records. Add cost weights or separate limits on expensive parameters where needed.

There is also a choice about behavior at the limit that is usually made by default rather than deliberately. Rejecting is honest and immediate. Queueing is kinder to the caller and dangerous for you, since a queue is a place latency accumulates and a way to run out of memory — which is the backpressure question rather than a gateway setting. Degrading — serving a cached or reduced response — is often the best answer for reads and needs the service’s cooperation.

Show consumers their limits, renewal rules, and usage before enforcement surprises them. If remaining-allowance headers or portal figures are approximate, delayed, or scoped to one gateway, label that scope. They should not imply a precise global balance that the counting system cannot provide.

Publishing is not the same as delivering

The developer portal helps consumers move from discovery to use. Azure API Management provides documentation, an interactive console, subscriptions and API keys, usage analytics, downloadable API definitions, and key management. Together these reduce setup work and make the service’s access process visible.

An interactive console makes a first request easier to try. Self-service subscription can automate preauthorized low-risk or sandbox access, while sensitive data and production writes may need review. Azure supports both administrator approval and automatic approval. A platform can provide self-service submission, status, and an approval service level without making every internal request automatic.

For example, set a two-hour first-call goal for new consumers whose accounts, prerequisites, and low-risk access are already approved. Test that cohort with someone outside the owning team. Measure required approval time separately from avoidable setup friction, and investigate the step that actually blocks progress rather than assuming credentials are always the problem.

Beyond the portal, four things make an API a supported product rather than an artifact.

• A named owner and a way to reach them. Not a shared inbox nobody watches.
• A stated support level — what consumers may expect of availability and response, and during which hours. Without that statement, consumers may plan around incompatible expectations.
• A change communication channel that reaches the people who integrated, which is rarely the same list as the people who subscribed.
• Per-consumer usage visibility helps both diagnosis and retirement planning. Zero observed calls is not proof of zero use: check observation periods, gaps, shared identities, consumer registries and owner confirmation. Combine that evidence with support commitments, notice, exceptions, and a recovery plan before retirement.

Treating the API surface this way — documented, self-service, owned, with a stated support expectation — is platform engineering applied to interfaces, and the portal is where the golden path for a consuming team either exists or does not.

What a gateway should not become

Azure API Management policies run in sequence on requests or responses and can be applied at global, workspace, product, API, or operation scope. Review those layers together: their combined behavior is part of the deployed interface.

Three design choices need explicit ownership and boundaries.

• Independently copied business rules. Reimplementing pricing or eligibility in a gateway can diverge from the authoritative domain implementation. Calling an owned decision service and enforcing its answer is different: the rules can remain centralized, but freshness, latency, outages, and state changes between decision and use still need a contract.
• Response transformations. A compatibility adapter or consumer-specific facade can legitimately change more than protocol details. Give it an owner, contract tests, and explicit rules for preserving domain meaning. The risk is an undocumented second interpretation of the service’s data, not transformation itself.
• Orchestration without an owner. Combining three backend calls at the gateway is a documented pattern, not a mistake in itself — it saves a chatty client several round trips, and Microsoft describes exactly that as gateway aggregation. What makes it a liability is doing it without the things a service gets by default: a name, a team, tests, and a deployment of its own. Left unowned, it is logic in the request path of everything sharing that gateway and nobody’s to fix. Two conditions push it out into a separate service regardless of ownership — resource demands or failure behavior that you do not want shared with other traffic, and a need to deploy or roll it back independently. And a simple read aggregation is a different proposition from long-running business orchestration, which wants durable state and belongs in a service either way.

Policy ownership, review, and tests make edge logic maintainable. Policies are text, so they belong in version control and in a pipeline, and vendors ship tooling for testing them: Azure’s policy toolkit lets policies be authored as code in a solution with a companion testing package, so expressions are covered by ordinary unit tests. The risk is organizational rather than technical, and it is worth naming as such. Ask who owns this policy, where it is reviewed, and what test fails if it is wrong; when the answers exist, a policy is a legitimate place for edge concerns. When they do not — when the honest answer is that someone edited it in a portal during an incident — that is the condition under which logic at the edge becomes unmaintainable, and it is a condition you can fix.

Alongside those policy controls, gateway logs, metrics, and traces provide request and credential evidence for capacity decisions and an audit log. A shared credential may not identify a person, and a gateway response may not establish the final business effect. Correlate request identifiers with backend authorization and observed outcomes to support those claims.

A workable division of labor

Stated as a short contract between the platform team and the service teams, the split that survives audits looks like this.

1. The gateway terminates TLS and validates the configured credential profile. For signed JWTs this includes trusted issuer and keys, permitted algorithms, token kind, and required claims and grants; reference tokens need provider validation or introspection, and sender-constrained tokens additionally need proof and key-binding checks.
2. The gateway enforces documented allocations and protective limits. Distinguish caller rate limits such as 429, general temporary overload such as 503, and product-specific quota responses. Provide a useful wait hint when available and bounded client fallback when absent.
3. The gateway passes the verified caller identity to the service in a form the service can trust, and the service treats a request arriving without it as unauthenticated rather than assuming it came through the front door.
4. The service authorizes every data access against that identity, every time, as if there were no gateway.
5. The service validates its own inputs beyond schema, and owns every business rule.

Verify the handoff of caller identity in an existing estate, because it is where the two halves are joined by an assumption. If a service can be reached directly — from inside the network, by a developer with a port-forward, by another service — then a caller who never passed the gateway gets whatever the service grants to callers it believes were authenticated. Network controls narrow that, and the service verifying the identity itself is what closes it.

A gateway pays for itself on the uniform, boring work — one place for credential verification, one place for limits, one place where traffic is observable — and it disappoints whenever it is bought as a substitute for services being correct. The most useful sentence a platform team can publish alongside it is the second column of that first table: here is what we check, and here is what remains yours.

References

• RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage
• RFC 6585, Additional HTTP Status Codes
• Microsoft Learn, Azure API Management: Overview and key concepts
• Microsoft Learn, Gateway Aggregation pattern
• RFC 9396, OAuth 2.0 Rich Authorization Requests
• RFC 6749, The OAuth 2.0 Authorization Framework
• RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• Microsoft Learn, Azure API Management policy reference — rate-limit
• Microsoft Learn, Azure API Management policy reference — quota
• Microsoft Learn, Recommendations to mitigate OWASP API Security Top 10 threats using API Management
• RFC 9068, JWT Profile for OAuth 2.0 Access Tokens
• RFC 8725, JSON Web Token Best Current Practices
• RFC 7662, OAuth 2.0 Token Introspection
• RFC 9110, 503 Service Unavailable
• RFC 2697, A Single Rate Three Color Marker
• Azure API Management Policy Toolkit