wolfeidau/website-openid-proxy

This service provides authenticated access to a static website hosted in an s3 bucket.

website-openid-proxy

This service provides OpenID authenticated access to a static website hosted in an s3 bucket.

It is designed to be a simple way to add authentication to static websites stored in AWS S3.

This service uses AWS API Gateway HTTP APIs and is powered by AWS Lambda.

How it works

1. Each request to the site checks for a session cookie prior to returning a response. If a user accesses the site for the first time users they are redirected to the OpenID provider.
2. User authenticates with the OpenID provider and is redirected back to the website as per the OAuth 2.0 Authorization Code Grant Type.
3. After authentication occurs the users info is retrieved, this includes sub and email, both of these are saved to the users session and logged when accessing content. PKCE is used to add an extra layer of verification for this exchange.
4. Uses the API Gateway version 2 format which includes support for cookies, this is translated to normal HTTP requests using apex/gateway.
5. GET requests are translated into GetObject requests which retrieve objects from the S3 bucket using wolfeidau/echo-s3-middleware. All these requests pass through the service.
6. The secret used to sign session cookies is stored in AWS Secrets Manager.

Cookies

This service uses two cookies to manage state, these are both signed using gorilla/securecookie with a secret generated by AWS Secrets Manager. Both cookies are also marked as secure and httpOnly in line with best practices.

For reference these cookies are:

• proxy_auth_session is used to store the oauth2 state variable during authentication and has an expiry of 5 minutes.
• proxy_login_session is used to check your logged in during the life of your session, this has an expiry of 8 hours.

Goals

1. Provide a simple authentication access to static websites hosted in s3.
2. Utilise AWS lambda and API Gateway to enable low cost hosting.
3. Take advantage of the rate limiting provided by AWS API Gateway to ensure access isn't possible using brute force attacks.
4. Use existing opensource libraries to provide secure access via cookies.
5. Support OpenID authentication of users accessing the site.

Deployment

You will need the following tools.

• AWS cli
• SAM cli

Also an aws profile setup with your aws credentials.

Create an OpenID application in a service such as Okta.

Create an .envrc file using direnv.

#!/bin/bash

export AWS_PROFILE=wolfeidau
export AWS_DEFAULT_PROFILE=wolfeidau
export AWS_REGION=ap-southeast-2

# these are provided by your OpenID provider 
export CLIENT_ID=xxxxxxxxx
export CLIENT_SECRET=xxxxxxxxx
export ISSUER=https://dev-xxxxxx.okta.com

export HOSTED_ZONE_ID=XXXXXXXXXX

# results in $SUBDOMAIN_NAME.$HOSTED_ZONE_NAME or something.wolfe.id.au
export HOSTED_ZONE_NAME=wolfe.id.au
export SUBDOMAIN_NAME=something

Run make.

make

TODO

• Add an example using AWS Cognito via OpenID.
• Add an example with Amazon Cloudfront in front of the API Gateway supporting the use of AWS WAF to enable IP whitelisting and other AWS managed rule sets for compliance.
• Provide some options to configure what cache headers for single page applications which already use cache busting for their assets.
• Containerise this service to enable running in AWS fargate or possibly kubernetes.

License

This application is released under Apache 2.0 license and is copyright Mark Wolfe.