API management RFP questions

In an OIDC setup, the gateway sits between clients and your identity provider and handles the protocol steps so that backend services receive only validated identities. With the authorization code flow, a user signs in at the IdP and the gateway exchanges the code for tokens; PKCE protects that exchange for public clients such as single-page apps and mobile apps. With the client credentials flow, a service or partner system authenticates as itself. Token introspection lets the gateway ask the IdP whether an opaque token is still active. The APISIX openid-connect plugin supports these flows, and the Kong OpenID Connect plugin is an Enterprise tier feature, so the gateway choice changes what you can deploy under open source terms. Confirm the exact flow and plugin support against the current documentation for the version you plan to run.

The partner should document five things before build starts. First, client registration: which clients exist in the IdP, their redirect URIs, grant types and who approves changes. Second, token validation: which issuer, audience, signature keys and expiry checks the gateway enforces, and how key rotation is handled. Third, scope mapping: how IdP scopes or group claims map to routes, consumers or plugin decisions, and who owns that mapping. Fourth, session handling: cookie settings, token lifetimes, refresh behavior and what happens at logout. Fifth, secret storage: where client secrets and signing material live, who can read them and how they are rotated. Ask for each item in writing, because it differs by IdP. Keycloak, Microsoft Entra ID, Okta, Auth0 and Google each expose claims and token settings differently.

Ask the partner to run a working flow test against your own IdP in a non-production environment before accepting the design. The test should show a real sign-in through the authorization code flow, a service token obtained through client credentials, an expired or revoked token rejected, and a token with the wrong audience or scope denied. Ask for the captured results and the configuration committed to version control, so you can repeat the test after upgrades. A flow that works only in a vendor demo tenant is not evidence for your environment.

A good answer maps each risk in the OWASP API Security Top 10 2023 to the layer that actually controls it. The gateway can enforce authentication at the edge, rate limits and quotas per consumer, and schema validation of request bodies and parameters. Object-level authorization and business logic stay in the application, because the gateway cannot know whether consumer A may read record B. Ask the partner to produce this mapping as a written table for your API estate before testing starts, and to mark each risk as gateway-enforced, application-enforced, or shared. A partner that claims the gateway covers the whole list should be asked to show the configuration that does it.

Next, ask how the partner tests both layers and what scope each test covers. For the gateway, ask which checks run against the live route definitions and plugin configuration, such as whether limit-count or equivalent rate limits apply to every consumer group, and whether requests bypassing the gateway are blocked at the network level. For the application, ask whether testing includes authenticated sessions for at least two roles, which is the only practical way to find broken object-level authorization. Ask which tools they use, whether testing is manual, automated or both, and whether the scope is agreed in writing with a named list of endpoints and environments. Confirm that production testing is allowed and under what change controls.

Finally, ask how findings are tracked and how retests are evidenced. Request the severity model, the ticketing system where findings land, the owner for each fix (gateway team or application team), and the criteria for closing a finding. A retest report should name the original finding, the evidence that the fix works, and the date of the retest. DeployOpen runs application and API security testing as a service, so ask us to show how a scope, findings register and retest evidence would be structured for your estate, and confirm with any partner what they will hand over at the end of each cycle.

Ask any partner how they will build your API inventory, and the answer should combine two sources: the gateway's own configuration and a discovery pass over live traffic. Routes, upstreams, consumers and plugins in the gateway describe the APIs you have published through it. They say nothing about the internal services that bypass the gateway, the old endpoints still receiving calls from a partner, or the shadow APIs that a team exposed directly. Ask the partner which discovery method they will use, whether it reads gateway access logs, service mesh telemetry or network flows, and how newly found endpoints are assigned an owner and a classification. An inventory built from only one source will look complete and still miss the APIs that carry the most risk.

Routes, plugins and upstreams belong in version control for the same reason application code does: every change needs an author, a reviewer and a history you can roll back. In a file-driven APISIX deployment, the conf/apisix.yaml file is the configuration itself, so the repository can hold the exact state the data plane loads. In Kong's DB-less or declarative setups, the equivalent is a declarative configuration file. Ask the partner to show a merge request that changes an authentication plugin, and to show the automated checks that run before it merges, such as schema validation, linting of route definitions, and a policy test that confirms protected routes still require authentication. Also confirm whether secrets are kept out of the repository and injected from a vault.

Two questions separate a workable design from a fragile one. First, how is drift between Git and the running gateway detected and corrected? Ask for the reconciliation job, its schedule, the alert it raises when a live route differs from the repository, and whether the correction is automatic or requires an approved change. Manual edits made through the Admin API should be either blocked or reported. Second, who holds the repository after handover? Agree in writing that your organization owns the repository, the CI pipeline definitions and the deployment credentials, that all branches and history transfer to you, and that the partner's access ends on a stated date. If the repository lives in your own Git server or hosted account from day one, this question becomes a checklist item rather than a negotiation.