This repo accompanies the blog post.
In that blog post a solution is explained, that puts Cognito authentication in front of (S3) downloads from CloudFront, using Lambda@Edge. JWT's are transferred using cookies to make authorization transparent to clients.
The sources in this repo implement that solution.
The purpose of this sample code is to demonstrate how Lambda@Edge can be used to implement authorization, with Cognito as identity provider (IDP). Please treat the code as an illustration––thoroughly review it and adapt it to your needs, if you want to use it for serious things.
This repo is the "sibling" of another repo here on aws-samples (authorization-lambda-at-edge). The difference is that the solution in that repo uses http headers (not cookies) to transfer JWT's. While also a valid approach, the downside of it is that your Web App (SPA) needs to be altered to pass these headers, as browsers do not send these along automatically (which they do for cookies).
This repo contains (a.o.) the following files and directories:
Lambda@Edge functions in src/lambda-edge:
- check-auth: Lambda@Edge function that checks each incoming request for valid JWT's in the request cookies
- parse-auth: Lambda@Edge function that handles the redirect from the Cognito hosted UI, after the user signed in
- refresh-auth: Lambda@Edge function that handles JWT refresh requests
- sign-out: Lambda@Edge function that handles sign-out
- http-headers: Lambda@Edge function that sets HTTP security headers (as good practice)
CloudFormation custom resources in src/cfn-custom-resources:
- react-app: A sample React app that is protected by the solution. It uses AWS Amplify Framework to read the JWT's from cookies. The directory also contains a Lambda function that implements a CloudFormation custom resource to build the React app and upload it to S3
- user-pool-client: Lambda function that implements a CloudFormation custom resource to update the User Pool client with OAuth config
- user-pool-domain: Lambda function that implements a CloudFormation custom resource to update the User Pool with a domain for the hosted UI
- lambda-code-update: Lambda function that implements a CloudFormation custom resource to inject configuration into the lambda@Edge functions and publish versions
- shared: Utility functions used by several Lambda@Edge functions
Other files and directories:
- ./example-serverless-app-reuse: Contains an example SAM template that shows how to reuse this application from the Serverless Application Repository in your own SAM templates.
- ./template.yaml: The SAM template that comprises the solution
- ./webpack.config.js: Webpack config for the Lambda@Edge functions and for the React-app custom resource
- ./tsconfig.json: TypeScript configuration for this project
The solution can be deployed with a few clicks through the Serverless Application Repository.
- Download and install Node.js
- Download and install AWS SAM CLI
- Of course you need an AWS account and necessary permissions to create resources in it. Make sure your AWS credentials can be found during deployment, e.g. by making your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY available as environment variables.
- You need an existing S3 bucket to use for the SAM deployment. Create an empty bucket.
- Ensure your system includes a Unix-like shell such as sh, bash, zsh, etc. (i.e. Windows users: please enable/install "Linux Subsystem for Windows" or Cygwin or something similar)
NOTE: Deploy this application to region us-east-1. This is because Lambda@Edge must be deployed to us-east-1 as it is a global configuration.
NOTE: Run the deployment commands below in a Unix-like shell such as sh, bash, zsh, etc. (i.e. Windows users: please run this in "Linux Subsystem for Windows" or in Cygwin or something similar)
- Clone this repo
git clone https://github.com/aws-samples/cloudfront-authorization-at-edge - Install dependencies:
npm install - TypeScript compile and run Webpack:
npm run build - Run SAM build. Use a container to support binaries:
sam build --use-container - Run SAM package:
sam package --output-template-file packaged.yaml --s3-bucket <Your SAM bucket> --region us-east-1 - Run SAM deploy:
sam deploy --template-file packaged.yaml --stack-name <Your Stack Name> --capabilities CAPABILITY_IAM --parameter-overrides EmailAddress=<your email> --region us-east-1
Providing an email address (as above in step 6) is optional. If you provide it, a user will be created in the Cognito User Pool that you can sign-in with.
See ./example-serverless-app-reuse
Deploy the solution (e.g. from the Serverless Application Repository) while setting parameter CreateCloudFrontDistribution to false. This way, only the Lambda@Edge functions will de deployed in your account, including a User Pool and Client. Then you can wire those Lambda@Edge functions up into your own CloudFront distribution. Create a behavior for all path patterns (root, RedirectPathSignIn, RedirectPathSignOut, RedirectPathAuthRefresh, SignOutUrl) and configure the corresponding Lambda@Edge function in each behavior.
The CloudFormation Stack's Outputs contain the Lambda Version ARNs that you can refer to in your CloudFront distribution.
When following this route, also provide parameter AlternateDomainNames upon deploying, so the correct redirect URL's can be configured for you in the Cognito User Pool Client.
This solution contains CloudFront and Lambda@Edge resources that must be deployed to us-east-1 (but will run in all Points of Presence globally).
This solution also contains an Amazon Cognito User Pool and S3 bucket, that should ideally be deployed in a region close to your users, to keep latency low. However, to keep the solution simple, these resources are included in the same template as the CloudFront/Lambda@Edge resources, and thus forced to be deployed to us-east-1 also.
If your users aren't near us-east-1 (North Virgina) and low latency is important enough to you, you can split this solution's SAM template into two separate templates:
- a template with CloudFront and Lambda@Edge resources, that you deploy to us-east-1
- a template with the Amazon Cognito User Pool and S3 bucket, that you deploy to a region closer to your users
NOTE: Even if your users aren't near us-east-1, latency might not bother them too much: latency will only be perceived by users when they open the Cognito Hosted UI to sign in, and when Lambda@Edge fetches the JWKS from the Cognito User Pool to validate JWTs. The JWKS is cached by the Lambda@Edge function, so as long as the Lambda@Edge function stays warm the JWKS won't need to be fetched again.
If you want to contribute, please read CONTRIBUTING, and note the hints below.
The sources that are not webpacked but rather run through sam build should have their dependencies listed in their own package.json files––to make sam build work properly.
For the sources that are webpacked this doesn't matter.
This sample code is made available under a modified MIT license. See the LICENSE file.