In Amazon API Gateway, does requiring an API key (the `x-api-key` header) authenticate the caller? What does an API key actually establish, and what would you add if you need real access control?
answer
- identity for metering, not a credential
- a static string in a header
- no signature, no expiry, no user
- pair it with a real authorizer
- possession is the whole proof
basics
~20 sNo. An API Gateway API key only identifies a client for metering and rate limiting — it is a static string in a header, not a credential. Real access control needs IAM SigV4, a Cognito or JWT authorizer, or a Lambda authorizer.
solid answer
~50 sAn API key is a plain string the client sends in the `x-api-key` header. API Gateway checks only that the key exists, is enabled, and is associated with a usage plan on the stage being called — it is not signed, not time-limited, and not bound to any user, so anyone who copies the value is indistinguishable from the legitimate client. AWS documents keys as a way to *identify* a client for metering and per-client rate limits, not to authenticate one. If you need to know *who* is calling and what they may do, set an authorization type on the method: `AWS_IAM` (SigV4-signed requests), a Cognito user pool authorizer, an HTTP API JWT authorizer, or a Lambda authorizer. The key can stay alongside that for client attribution. Note that API keys and usage plans exist on REST APIs; HTTP APIs do not support them.
code
bash · 4 lines# The key labels the client; the bearer token is what actually authenticates it.
curl -sS https://abc123.execute-api.us-east-1.amazonaws.com/prod/orders \
-H "x-api-key: $PARTNER_API_KEY" \
-H "Authorization: Bearer $ACCESS_TOKEN"go deeper
Know that x-api-key only labels a client for metering, and say plainly that authentication needs an authorizer or SigV4. Do not describe the key as a password.
Explain the three checks API Gateway makes on a key, why possession is the entire proof, and how a key composes with a Lambda or JWT authorizer rather than replacing it.
Show you would refuse a design where a key embedded in a distributed client is the only control, and describe sourcing the key from the authorizer so clients never handle one.
Own the boundary decision: what belongs at the gateway as identity versus what is merely commercial metering, and how partner onboarding, key rotation and revocation work when a key is only a billing label.
## What an API key actually is An API key in Amazon API Gateway is a string value that you generate in (or import into) API Gateway and hand to a client. When a REST API method is configured with "API key required", the caller must send that value in the `x-api-key` header. API Gateway then performs exactly three checks: the key exists, the key is enabled, and the key is associated with a usage plan that is attached to the stage being invoked. If any of those fail, the request is rejected with `403 Forbidden` before your integration is ever called. Notice what is *not* on that list. The key is not signed. It does not expire on its own. It carries no claims, no user identifier, and no scope. Nothing about the request — path, body, timestamp — is bound to it. ## Why that is not authentication Authentication means producing evidence about who is calling that an impostor cannot manufacture. A SigV4 signature is such evidence: it is an HMAC computed over the request using a secret that never travels on the wire, so replaying it elsewhere fails. A signed JWT is such evidence: a verifier checks a signature it did not have to trust the sender for. An API key is a *bearer string*. Possession is the whole of the proof. It is transmitted in full on every request, it is usually long-lived, and it is typically shared by every instance of a client. Anyone who reads it from a log, a mobile app bundle, a browser's network tab, or a committed config file becomes that client. AWS's own guidance is explicit that API keys should not be used as the sole means of identifying or authorizing API clients. A second, subtler point: even if the key *were* unguessable, it identifies an **application**, not a **person**. A per-tenant key tells you which partner integration is calling; it tells you nothing about which of that partner's users triggered the call, so it can never drive per-user authorization decisions. ## What the key legitimately buys you - **Client attribution.** Requests get tagged with a caller you can name in logs and metrics. - **Per-client limits and metering.** The key is what associates a caller with a usage plan, which is the mechanism for per-client throttling and quotas. - **A cheap kill switch.** Disabling a key cuts off one partner without touching the rest. - **Noise reduction.** Unkeyed scanners get a `403` at the edge rather than reaching your backend. Those are all real operational value. None of them is a security boundary. ## What to use instead — or alongside Set an authorization type on the method: - **`AWS_IAM`** — the caller signs the request with SigV4 using AWS credentials, and access is decided by `execute-api:Invoke` permissions. Right for service-to-service and cross-account callers. - **Cognito user pool authorizer** (REST APIs) — API Gateway validates a token issued by a user pool you point it at, and exposes the claims to your integration. - **JWT authorizer** (HTTP APIs) — built-in validation against any OIDC issuer you configure by issuer URL and audience. - **Lambda authorizer** — your own function inspects the request and returns an IAM policy, for anything the built-ins do not cover. Keys and authorizers compose. A common production shape is a Lambda or JWT authorizer for identity plus an API key for per-partner metering. API Gateway even supports sourcing the key from the authorizer instead of the header: set the API key source to `AUTHORIZER` and have your Lambda authorizer return `usageIdentifierKey`, so the client never handles a key at all and the authorizer decides which usage plan applies. ## The failure this question is really testing The interviewer is checking whether you would ship a public mobile or single-page app whose "security" is a key baked into the client bundle. That key is extractable in minutes with the browser's developer tools or by unpacking the app. The correct answer is that the key is fine as a client label, and something that verifies a signature or a token must sit in front of anything you actually care about. One more trap: HTTPS does not rescue a bearer key. TLS protects the value in transit; it says nothing about whether the entity presenting it is the entity you issued it to.
- Where does API Gateway look for the API key, and can a Lambda authorizer supply it instead of the client?By default the API key source is the `x-api-key` header. You can instead set the API's key source to `AUTHORIZER`, in which case a Lambda authorizer returns `usageIdentifierKey` in its response and API Gateway uses that value to pick the usage plan. The client then never holds a key, and the authorizer decides which plan a caller falls under.
- If API keys are not authentication, when are they still the right tool?When you need to tell partner integrations apart for metering, per-client rate limits, log attribution, or a quick per-partner off switch — always behind a real authorizer. They are a label on traffic, not a gate. They are also useful for a fast tiering change that does not require reissuing credentials.
- What changes if the API is an HTTP API rather than a REST API?HTTP APIs do not support API keys or usage plans at all. You identify callers through the authorizer instead — a JWT authorizer's claims or a Lambda authorizer's returned context — and apply limits per route. If a design depends on API keys, that requirement alone can push you to a REST API.
saying these in an interview costs you the question
- Calls the API key a secret that authenticates the client
- Assumes an API key identifies an end user
- Ships the key inside a browser or mobile app and calls it secure
- Thinks HTTPS makes a bearer key safe from theft
- Believes rotating keys removes the need for an authorizer