API gateway buyer’s guide: evaluation criteria that matter

Most API gateway selections are decided on routing features and developer portals, and the security behaviour that actually stops abuse is checked only after the contract is signed. A gateway becomes the runtime enforcement point for every API it fronts: it validates tokens, binds clients to credentials, applies quotas, holds backend secrets and produces the audit trail. Products sold as API gateways range from cloud-managed services to self-hosted proxies, ingress controllers and full API management suites, and they differ most in exactly the places buyers rarely test. This vendor-neutral buyer's guide sets out how to define requirements, the capability areas and weighted criteria to score, the questions that separate products, red flags and a proof of concept built around failure modes. It does not name or rank products. How to configure a gateway securely is covered in the API Gateway Security Guide; this page helps you choose one.

Key takeaways

• Score token validation, not token support. Every gateway "supports JWT". What matters is whether issuer, audience, algorithm and expiry checks are enforced by default and cannot be silently loosened per route.
• Demand sender-constrained tokens for machine clients. RFC 9700 says resource servers should use mutual TLS (RFC 8705) or DPoP (RFC 9449) so a stolen token alone is not enough; check the gateway can verify both.
• Test failure behaviour in the proof of concept. Ask what happens when the identity provider, key set endpoint or external authoriser is unreachable, and accept only fail-closed answers you have observed.
• Treat the gateway as a privileged non-human identity. It holds TLS keys, backend credentials and client secrets, so its admin plane, secret storage and deployment identities are part of the evaluation.
• Buy the inventory as much as the proxy. The gateway configuration should be the authoritative list of exposed routes and their owners, which is the control behind OWASP API9:2023 Improper Inventory Management.

Define requirements

NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems (final, updated 13 March 2026 with appendices listing API risks by category and recommended controls by lifecycle stage), recommends an incremental, risk-based approach that separates pre-runtime from runtime controls. Use that split to keep the gateway requirement honest: it is a runtime enforcement point, not a substitute for secure API design or object level authorisation in the service. Before talking to suppliers, write down:

• Traffic patterns: north-south (internet, partner, mobile) versus east-west (service to service). NIST SP 800-204 notes that authentication, access management, secure communication, throttling and circuit breaking can be packaged in either an API gateway or a service mesh. See API Gateway vs Service Mesh before buying one product for both.
• Caller types: browser and mobile apps, partner systems, internal services and AI agents. Machine callers need per-client identity and lifecycle, not a shared key. If model traffic is in scope, read AI Gateway vs API Gateway.
• Identity providers: which authorisation servers issue tokens, whether tokens are JWTs or opaque (needing RFC 7662 introspection), and whether multiple tenants or issuers must be accepted.
• API styles: REST with OpenAPI specifications (the current OpenAPI Specification is 3.2.1, dated 10 September 2026), GraphQL, gRPC, WebSocket or event streams. Each needs different limits and validation.
• Edge layering: whether a WAF, bot management or DDoS service sits in front. See WAF vs API Gateway to avoid paying twice or leaving gaps.
• Operating constraints: regions and data residency, required availability, added latency budget at the 99th percentile, and who will run it.

Small versus large organisations: a small team with a handful of APIs and one identity provider is usually best served by one managed gateway with a standard policy set. A large organisation typically needs a central policy baseline, delegated route ownership per API team, configuration in code checked in CI, and often two tiers: an edge gateway for external traffic and a mesh or lightweight gateway internally.

Capability areas

• Token validation: issuer and audience pinning, algorithm allow list, rejection of unsigned tokens, expiry and not-before checks, small configurable clock skew, automatic key set retrieval with rotation, and per-operation scope or claim checks. RFC 8725 requires recipients to validate aud where one issuer serves several relying parties, and to use only allowed algorithms.
• Sender-constrained tokens: verification of certificate-bound tokens (the cnf claim with x5t#S256 under RFC 8705) and DPoP proofs (method, URI, issue time, access token hash and replay window under RFC 9449). See the DPoP Guide and the mTLS Guide.
• Opaque tokens and introspection: authenticated calls to the introspection endpoint, configurable cache lifetime that never exceeds token expiry, and a choice to disable caching for sensitive routes, as RFC 7662 describes.
• Client credential lifecycle: per-client registration with owner, scopes, expiry and last-used date; key rotation without downtime; instant revocation. API keys are for identification and metering, as the API Keys vs OAuth Tokens Guide explains.
• Contract enforcement: import of OpenAPI or equivalent specifications, default-deny for routes not in the specification, request schema validation, method allow lists (405), content type checks (415) and body size limits (413), as the OWASP REST Security Cheat Sheet recommends.
• Consumption controls: rate and burst limits keyed on client and token subject, quotas, concurrency limits and query depth or cost limits for GraphQL, mapping to OWASP API4:2023 Unrestricted Resource Consumption. See the Rate Limiting and API Abuse Guide.
• External authorisation: callouts to a policy engine with explicit fail-closed configuration, decision caching with bounded lifetime, and latency metrics.
• Secrets and keys: backend credentials and TLS private keys referenced from an external secrets manager or hardware-backed store rather than pasted into policy (SP 800-53 SC-12, SC-28).
• Admin plane: single sign-on with phishing-resistant MFA, granular roles, management API off the public data path, configuration as code, and an immutable audit log of changes.
• Telemetry: structured per-request logs with client ID, subject, route, status, sizes, latency and policy decision, exported to the SIEM, with token redaction.

Evaluation criteria

Object level authorisation (API1:2023) needs ownership data that only the backend holds, so do not score a gateway on it beyond passing a trustworthy caller identity downstream.

Questions to ask vendors

• Defaults: Which token checks are on by default, and can a route owner disable audience or issuer validation without a central reviewer seeing it?
• Algorithms: How is the accepted algorithm set configured, and is it taken from configuration rather than the token header?
• Outages: What happens to requests when the key set endpoint, introspection endpoint or external authoriser times out? Is that configurable per route, and is fail-open logged?
• Proof of possession: Can the gateway verify certificate-bound tokens and DPoP proofs, including nonce support and replay detection across clustered nodes?
• Identity propagation: How is the validated caller identity passed to backends, and does the gateway always strip client-supplied copies of that header?
• Secrets: Where are TLS private keys and backend credentials stored, and do configuration exports or support bundles ever contain them?
• Admin plane: Can the management API be reachable only from a private network? Which actions are recorded in the admin audit log, and can it be streamed out in real time?
• Control and data planes: In hybrid models, how does the data plane authenticate to the control plane, and what happens to traffic if that link is lost?
• Inventory: Can we export every route with its owner, specification, authentication method and last change through an API?
• Security response: Where are security advisories published, what is the typical time from fix to release, and how are self-hosted customers notified?

Red flags

• "JWT supported" with no detail: the vendor cannot show where issuer, audience and algorithm restrictions are set, or examples omit them.
• Fail-open as the default for external authorisers or introspection, or no answer to the outage question.
• API keys presented as authentication for sensitive routes, with no per-client OAuth or mTLS option.
• Secrets in plain configuration: backend passwords or private keys visible in exported policy files or the console.
• Shared admin accounts or management endpoints on the public data path, contrary to the OWASP advice to keep management endpoints off the internet.
• Wildcard routing encouraged in quick-start guides, so unknown paths reach backends.
• Limits keyed on source IP only, which attackers rotate around. Six weeks of unnoticed bulk retrieval through one API in the T-Mobile API breach (2023) shows why per-client volume alerting matters.
• No public security advisory channel or patch history for self-hosted editions.

Proof of concept

1. Pick representative APIs: one public REST API with an OpenAPI specification, one partner machine-to-machine API and, if relevant, one GraphQL or streaming API.
2. Load your baseline policy as code: token validation with issuer and audience, default rate limit, size limits, logging fields and default-deny routing.
3. Run negative token tests: wrong audience, foreign issuer, expired, unsigned, unexpected algorithm, and a valid token replayed from a different client. Every one must be rejected with 401, and valid tokens without scope with 403.
4. Break dependencies: block the key set endpoint, the introspection endpoint and the policy engine in turn. Record whether traffic is rejected and how quickly it recovers.
5. Test sender constraint: present a certificate-bound token over a connection with a different certificate, and a DPoP proof with a mismatched method or reused identifier.
6. Check contract enforcement: call an undeclared route, an unsupported method and a body with unknown fields.
7. Load test limits: drive one client past its quota and confirm 429 for that client while others are unaffected, and measure added latency at the 99th percentile.
8. Inspect the admin plane: export configuration and search it for secrets, change a policy and confirm the change appears in the audit log and the SIEM, then roll it back to the previous version.

After selection, track a small set of measures: share of external API traffic passing through the gateway, routes without authentication outside a documented public list, clients with an owner and expiry, mean time to revoke a client credential, and days to apply gateway security updates. The API gateway health check gives a recurring review cadence, and the API gateway migration playbook covers moving routes from an existing gateway.

Standards and references

• NIST: SP 800-228, Guidelines for API Protection for Cloud-Native Systems
• NIST: SP 800-204, Security Strategies for Microservices-based Application Systems
• OWASP: API Security Top 10 2023
• IETF: RFC 9700, Best Current Practice for OAuth 2.0 Security
• IETF: RFC 8725, JSON Web Token Best Current Practices
• IETF: RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• IETF: RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• OWASP: REST Security Cheat Sheet

How NHI Mgmt Group can help

We provide independent market analysis, RFP strategy and evaluation support for identity, NHI and API security programmes, including API gateway selection. Browse vendors in our NHI and AI products directory or contact us about independent evaluation support.

Related NHI Mgmt Group resources: API Gateway Security Guide · API Security Buyer's Guide · JWT Security Guide · API Key Management Guide · API gateway health check