Lambda@Edge not successfully forwarding modified request body with SecretHash to Cognito
I'm using a CloudFront distribution with a Lambda@Edge function as a secure proxy for a Cognito User Pool. The purpose of the function is to intercept outbound POST requests to Cognito, inject a SecretHash into the request body (required because my User Pool has a client secret), and forward the modified request to the Cognito service endpoint. The function is configured as an origin request trigger with Include Body enabled. I can confirm via CloudWatch logs that the SecretHash is being correctly generated and the request body is being successfully modified before being returned via the callback. However, despite this, Cognito continues to reject the request as though the SecretHash was never added. My current configuration:
Trigger type: Origin Request Include Body: Yes Path pattern: /auth* Origin: cognito-idp.<region>.amazonaws.com Body encoding after modification: base64
What I've confirmed:
The SecretHash is being correctly calculated The modified body is being correctly base64 encoded The updated request is being logged and returned via the callback The function is hitting the correct Cognito operations (e.g. SignUp, InitiateAuth) and injecting SecretHash in the correct location for each
Question: What is the recommended way to ensure a modified request body from a Lambda@Edge origin request trigger is correctly forwarded to Cognito? Are there any known issues or additional steps required when modifying the request body at this stage that I might be missing?
- Topics
- ServerlessNetworking & Content DeliverySecurity, Identity, & ComplianceAWS Well-Architected Framework
- Language
- English
asked 8 months ago179 views
- Newest
- Most votes
- Most comments
In Lambda@Edge origin-request, CloudFront won’t forward your edited payload unless you replace the body. Return the request with:
request.body.action = "replace"
request.body.encoding = "base64" (or "text")
request.body.data = "<modified body>"
Then remove or recompute Content-Length to match the new bytes (stale length can cause truncation). Also ensure inputTruncated is false and required headers (content-type, x-amz-target) are forwarded.
Relevant content
asked 4 years ago
- AWS OFFICIALUpdated 2 years ago
Hey Venkata. The solution you proposed has worked, thank you very much. I didn't need to remove or recalculate Content-length in this case, it appears CloudFront handled that automatically after I set the body.action to "replace". Thanks again!