I want to use IAM Auth in API Gateway for Machine 2 Machine authorization for internal components, the main driver for using IAM Auth is the way we can use resource policies with it and allowing Org OUs etc. to trigger the API Gateway which is not possible with a Lambda Authorizer, see https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-aws-condition-keys.html
We have a lot of existing downstream applications that is using the Authorization header for determining the end-users scopes and permissions, verifying the Bearer token value within the Authorization header towards another IdP. It is very hard to change this header to something else as it is about 400 microservices using it currently. The problem is basically when something is fronted externally which is Authorizing an end-user using a Lambda Authorizer, and then this application communicates to some other component internally that will use IAM Auth(M2M Auth), and this other component needs to determine the users permissions to respond with the right data. Eg. End-user -> Application(Lambda Authorizer) -> Other Application (IAM Auth), and this needs the Authorization header. The other application in this case could of course be a private API Gateway but the workarounds for using custom domain names is not very appealing to me.
When the application(s) consumes the API Gateway with IAM Auth it signs the Sigv4 signature using query strings and pre signed urls due to bearer token already existing in the Authorization header. But my problem is that when using IAM Auth in API Gateway it will drop the Authorization header which means that the existing bearer token will be lost, see https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html
Does anyone have a workaround for this?
I have been thinking on putting a CloudFront in front of the API Gateway and use a Lambda@Edge that will switch the Authorization header name, and the use a request template in API Gateway to switch it back. But according to a AWS support engineer this will not work as the API Gateway will be unable to trigger the integration behind the API Gateway (I haven’t verified this yet though) I have also been considering using mTLS instead but it is a lot more work to get in place at scale and handle its lifecycle.
Authorization options that I’ve considered:
Lambda Authorizer, not feasible due to limited resource policy.
Private API Gateway, not feasible due to custom domain name limitations.
mTLS, might be a choice but it adds complexity.
API Gateway with IAM Auth, drops Authorization header as mentioned.
