I currently have created an API Gateway using AWS. This gateway requires an API Key that is stored on AWS. From what I've seen, the correct way to pass this key in the header is to use x-api-key. For continuity, I was hoping there would be a way to pass the key in the header of the POST using key Authorization instead of x-api-key. From what I've read though, since this gateway is hosted in aws, x-api-key is the only way to pass the key. Is there a workaround to this?
Authorization Header In Place Of x-api-key
Viewed 1042
1 Answers
Lambda Authorizer
IMO it is easier if you just stick with the convention, it's actually a bit of work to change this. You need to create a Lambda Authorizer. This will be a Lambda function that will return the iam policy for a given request to your gateway, but also an optional context. This context can contain what API key should be used, although you need to keep in mind that your Lambda function does the Authorization, this key is used only in the usage plan I believe.
So to summarize when you create your authorizer you will pick the header that is used Authorizaion in your case. In you Lambda function you reference this header here: event.authorizationToken. Using that header you construct your iam policy, this may mean you need to manually look up this API key if it does have access to your API. Your Lambda function will also need to set the the api-key to the $context.authorizer, which contains the api key you want to use, which will be event.authorizationToken in your case. That will apply the UsagePlan to your API.
CloudFront
Another option is to create a CloudFront distribution in-front of your API and add the header in manually yourself. This will probably cost more though because you will need a CloudFront distribution and then your Lambda@Edge will execute with every request. As opposed to a Lambda Authorizer which can be cached. You can find an example here.
Related