The secret of throttling API requests without ‘x-api-key’ request header
Amazon API Gateway offers a smart solution to throttle and rate-limit API clients that do not send API keys in the request header
Throttling and rate-limiting API requests with Amazon API Gateway happens to be very straightforward. The API provider shares a unique API key with the API client and the client is expected to send that key in the x-api-key HTTP header, along with the request. At the API Gateway level, this key is associated with a usage plan, which in turn, is associated with API stages and methods. API Gateway compares the incoming key against all the keys in the usage plan for the specific API and if a match is found, applies the throttling and rate-limiting policies as per the usage plan. API Gateway sends HTTP 429 (Too Many Requests) in response if the requests do not comply with these policies. Pretty simple.
However, things can get a little tricky when the API clients are unable to send API-key along with the request. May be because, that would require changes at the client side which is not feasible due to time and/or effort constraints. Amazon API Gateway provides an elegant solution to this problem.
Amazon API Gateway supports two types of sources for API key- header (default) and authorizer. So far, we have been discussing the “header” option where the API key is sent by the clients as part of the request header. Now let’s take a dive into the authorizer option which holds the secret sauce.
Solution
Authorizer sourced API keys are essentially API keys that are returned by the Lambda authorizer (instead of API clients sending the API keys as header along with requests), based on application specific logic backed by some custom ontology. At this point, it is worth mentioning that a Lambda authorizer is essentially AWS Lambda function that could be used to authorize API requests.
Read the following blog to know more about how to create and setup a Lambda authorizer.
The API key is returned along with the authorization response of the Lambda authorizer as the value of the root level property- usageIdentifierKey. A Lambda authorizer response might then look like:
{
"principalId": "client",
"policyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
"Effect": "Allow"
}
]
},
"usageIdentifierKey": <api-key>
}The logic of selecting the API key gets implemented within the Lambda authorizer and could be based on some other request header parameters (like client identifier, etc.).
In essence, instead of the API client having to explicitly send API key in the request header, the API key gets returned by the intermediate Lambda authorizer and gets automatically used by Amazon API gateway. Amazon API gateway subsequently picks up the right usage plan to apply throttling and rate-limiting policies to the request.
That’s all folks! Happy learning…
