cloudfront: Failed to forward Authorization header from cloudfront to API Gateway

[apoorvmote]

I am using distribution HTTP API with cloudfront. And I want to pass Authorization header from cloudfront to HTTP API lambda authorizer. And I am not able to whitelist any header from cloudfront.

Reproduction Steps

In brand new CDK Projest just create the following policy

    new OriginRequestPolicy(this, 'testOriginPolicy', {
      cookieBehavior: OriginRequestCookieBehavior.all(),
      headerBehavior: OriginRequestHeaderBehavior.allowList('Authorization'),
      queryStringBehavior: OriginRequestQueryStringBehavior.all()
    })

What did you expect to happen?

I expcted to successfully deploy the origin policy. I haven't even attached to cloudfront distribution yet.

What actually happened?

The deploy fails with following error

Invalid request provided: AWS::CloudFront::OriginRequestPolicy
The following resource(s) failed to create: [testOriginPolicyBBC7F32C].

Environment

• CDK CLI Version : 1.91.0
• Framework Version:
• Node.js Version: v14.16.0
• OS : Ubuntu 20.04 on WSL2
• Language (Version): Typescript ~3.9.7

Other

---

This is 🐛 Bug Report

[robertd]

@apoorvmote You can't pass Authorization header behavior when creating OriginRequestPolicy. I'd suggest using CachePolicy instead if you need to pass auth header (see links below).

See these references for more info:

• https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-authorization-header/
• AWS::CloudFront::CachePolicy and AWS::CloudFront::OriginRequestPolicy aws-cloudformation/cloudformation-coverage-roadmap#571

[robertd]

@njlynch I couldn't really find anywhere in docs that Authorization header is not allowed when creating OriginRequestPolicy. Should we check header OriginRequestHeaderBehavior values just in case so users don't find this out the hard way during deployment?... just to be on the safe side

[robertd]

@njlynch Accept-Encoding is also not allowed...

And I found out there is limitation on how many headers you can whitelist (total of 10).

AFAIK... none of this is captured anywhere in OriginRequestPolicy docs. Should we check all this when creating OriginRequestPolicy resource for better user experience?

[apoorvmote]

@robertd Thanks very much for quick reply. I though I had to wait many days before anyone will take a look at it.

I would like help setting Cache Policy because its for API endpoint I have been using static CachePolicy.CACHING_DISABLED

Now to allow Headers I need to recreate the CACHING_DISABLED and add whitelist for header.

I was working on workaround. Instead of passing token through header I was going to pass it through body.

https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-apigatewayv2-authorizers.UserPoolAuthorizerProps.html#identitysourcespan-classapi-icon-api-icon-experimental-titlethis-api-element-is-experimental-it-may-change-without-noticespan

Changing identitySource from $request.header.Authorization to $request.body.Authorization

Is there any security concern by passing token via body? or I MUST pass token via header?

[njlynch]

I would like help setting Cache Policy because its for API endpoint I have been using static CachePolicy.CACHING_DISABLED. Now to allow Headers I need to recreate the CACHING_DISABLED and add whitelist for header.

This is actually reasonably straightforward. Simply create a new CachePolicy with 0s for all TTLs, and add the header policy. Then use this new cache policy with your distribution.

const cachePolicy = new cloudfront.CachePolicy(stack, 'CachingDisabledButWithAuth', {
  defaultTtl: Duration.minutes(0),
  minTtl: Duration.minutes(0),
  maxTtl: Duration.minutes(0),
  headerBehavior: cloudfront.CacheHeaderBehavior.allowList('Authorization'),
});

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[bblanke]

Quick addition to @njlynch 's response. I had to set at least 1 of the TTL's to something in order to create the cache policy, so I set max TTL to 1 second:

const cachePolicy = new cloudfront.CachePolicy(stack, 'CachingDisabledButWithAuth', {
  defaultTtl: Duration.minutes(0),
  minTtl: Duration.minutes(0),
  maxTtl: Duration.minutes(1),
  headerBehavior: cloudfront.CacheHeaderBehavior.allowList('Authorization'),
});

[ischia-exigenter]

Quick addition to @njlynch 's response. I had to set at least 1 of the TTL's to something in order to create the cache policy, so I set max TTL to 1 second:

const cachePolicy = new cloudfront.CachePolicy(stack, 'CachingDisabledButWithAuth', {
  defaultTtl: Duration.minutes(0),
  minTtl: Duration.minutes(0),
  maxTtl: Duration.minutes(1),
  headerBehavior: cloudfront.CacheHeaderBehavior.allowList('Authorization'),
});

Seeing the same issue, and it happens if you try to create a stand-alone cache policy in the AWS Console. You get the annoying error: "The parameter HeaderBehavior is invalid for policy with caching disabled."

However, if you manually modify caching on a CloudFront distribution, somehow AWS Console allows it. So "yes, we want caching disabled, and YES we want to pass an API Token, or other authorization header to the API Gateway!!"

[daverickdunn]

So I've spotted a nasty issue using @bblanke's solution. If you batch requests with the same path (different headers and/or different query params), CF/APIGW will (not always, but almost always, probably due to load balancing) give them all the same requestId (see, x-amzn-requestid response header). If one of the requests fail, they all fail, and they all continue to fail on retry, so this appears to be related to the caching mechanism. I'm fairly sure this is a bug on AWS's end and it makes this unusable for me. I suspect the effects of this could be bigger than the scenario I'm experiencing, so be careful using this solution.

[nidhin-raj]

If the origin is API Gateway, then it is recommended to use

cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED,
originRequestPolicy: cloudfront.OriginRequestPolicy.fromOriginRequestPolicyId(this, 'AllViewerExceptHostHeader', 'b689b0a8-53d0-40ab-baf2-68738e2966ac')

AllViewerExceptHostHeader comes from https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-origin-request-policies.html, cdk-lib hasn't included this policy yet. hopefully soon.