Title says it all: is it possible to host a static-generated site on S3 and restrict access to it based on Github OAuth?
Scenario: You generate a static site (using Hugo or whatever) and you upload it to S3 as a static site. Is there some combination of AWS services (API Gateway, Lambda, etc.) that can make it so that only members of my Github organization can access this site? Authenticating with Github's OAuth? Anyone not authenticated should be treated with a 404.
Has anyone done this or know how to do it? Is such a thing possible without running a backing server (EC2, Heroku, DigitalOcean Droplet, etc.) of some kind?
Looking for a complete answer that outlines steps on how to set this up (if possible) with the lowest cost/complexity.
Yes this is possible. I've followed this tutorial in the past to secure a static site on S3 behind an Auth0 authentication, using DynamoDB as the user account store, and API Gateway + AWS Lambda as the authentication service. That was an AngularJS SPA, but the general concept should be the same.
Github is listed as an Auth0 identity provider. I would recommend looking at this documentation for using Auth0 on your site. Once you get it working you would have to configure your static site generator to include the authentication JavaScript code on every page it generates.
Related
I want to create a user pool for the purposes of requiring authentication on my website. I have a website deployed using CloudFront. I have one hosted zone for this website on Route 53. I have tried setting up a Cognito, but I have been unsuccessful.
During the set up process, it asks for the app name. I can not figure out if this is asking for an existing app name or if I need to make one up. The significance of this step is not clear. Another step in the process has me enter the domain name, either an Amazon Cognito domain, or my own custom domain. I tried using an Amazon Cognito domain, but after following the AWS documentation and visiting my new domain, I only saw an error message.
I wish to connect a pre-existing, and pre-deployed website with its own sign-in page to AWS Cognito, but I cannot find any solid guides on how to do so. Any help would be greatly appreciated.
After much searching and reading through numerous posts and documentation, I found the answer to my questions. I ended up following an AWS GitHub Wiki to set up the authentication flow.
The Route 53 service ended up not being relevant for this task. Amplify is not required. The name of the Cognito app was not significant, it only gives the user pool an app name. On the AWS side, I had to create my own user pool following this AWS doc. On the website side, I had to create a user and a user pool in JavaScript using the SDK described in the linked wiki.
The wiki lists different ways to install and include the Cognito SDK within a JavaScript project. The configuration steps needed to be tweaked slightly to fit within the framework I am using. Numerous use cases are covered.
Building my first full stack website. I have an architecture doubt.
What I have:
golang backend
react frontend
auth0 authentication
aws amplify
I am considering to create this architecture, I think that I am misleading with something. The front-end connect direct with s3 bucket to put private images there, but I am not sure if I should do it direct or send the request to my server and then the server update the s3. Searching for solutions, it seams that amplify is great for serverless, but in my application should I change amplify for cloudfront?
You can upload directly from frontend. But make sure you are sanitizing the files you upload. The downside is you will have to add you AWS S3 access credentials in frontend.
If you do it through your server, which I assume to be an AWS service you can give access to S3 for that service through IAM and no credentials required to be stored. And the downside here is an additional hop and latency while uploading big files.
It's a choice for you to make based on your requirements now.
My use case is fairly simple: I want to deploy a frontend to production that uses an Amplify backend, without exposing sensitive config like the API key.
I have a frontend that uses Github Actions for CI and CD and deploys to Zeit Now (since it's a Next.js project and needs SSR support, which Amplify currently does not provide). At the moment it does not have a backend connected so it deploys to production without any issues.
In the same project I've set up AWS Amplify for the backend and connected it to the frontend. It all works sucessfully as expected from a local environment.
Now I want to deploy the frontend to production, however the AWS config for connecting it to the backend, it's saved in an autogenerated file named aws-exports.js which contains amongst other things the GraphQL end point and its API key. This file has been added to the .gitignore by the Amplify CLI.
If I remove the aws-exports.js files from the .gitignore and commit it to the repository, I think it would probably work once deployed to production, however I assume this is not a good idea since I would be exposing sensitive config data.
I don't want to use AWS to deploy my frontend, which is what's suggested as solution in the documentation I've read about this. Is there any recommended way to do this keeping the frontend and backend environments separated? (meaning the frontend still being deployed to Zeit Now which will use the backend deployed in AWS).
As far as I understand the AWS AppSync security concept designates the auth model API_KEY to usage in either public applications or development environments.
Unauthenticated APIs require more strict throttling than authenticated APIs. One way to control throttling for unauthenticated GraphQL endpoints is through the use of API keys.
An API key is a hard-coded value in your application that is generated by the AWS AppSync service when you create an unauthenticated GraphQL endpoint.
I do not think that there is any benefit in trying to hide an API key. If authentication is required, it must be provided by other means than a hard-coded secret which is always extractable from public apps (such as web frontends).
There are more auth models described in the docs. [1]
If you are planning to develop an app with private endpoints and a public frontend/client, you should definitely use another auth model - most likely OPENID_CONNECT or AMAZON_COGNITO_USER_POOLS.
I think you should first read the AWS blog post titled GraphQL API Security with AWS AppSync and Amplify [2] and afterwards stating your question more precisely if any lack of clarity should remain.
References
[1] https://docs.aws.amazon.com/appsync/latest/devguide/security.html#api-key-authorization
[2] https://aws.amazon.com/de/blogs/mobile/graphql-security-appsync-amplify/
My team made a custom Cognito login page using normal AWS SDK JS code that logs users in for a given domain name, functioning via cookies. Now we are asked to support multiple domains, which can't be done via the cookie system, so I am looking into OAuth2. The huge problem with OAuth2 is that I can't find any documentation on how to do OAuth2 using one's custom login page.
The previous best answer on this subject is at AWS Cognito Authorization code grant flow without using the hosted UI, but that is now about 2 years old, and I can see that the POST occurring on the hosted login page now includes another base64 piece of information not provided by the old answer, so I am skeptical that answer will still work. Is there still no way to generate the authorization code grant without using the hosted UI?
I'm coding from my garage, already deployed a GCloud Function, but don't have a corporate website yet. So my application origin URI is localhost:### so far. Now I want to integrate my web project with my GCF, following Integrating Google Sign-in I'm stuck because I just don't have a registered website for origin URI
Is an official website URI required to proceed?
Yes, a URI is required. On top of that it needs to be HTTPS, which requires an SSL certificate. The exception is testing with localhost.
The reason is that when you use OAuth 2.0 to authenticate a user, the user goes to Google Accounts and authenticates. Then Google Accounts calls your callback URL to give you a token. This is part of the security design. If you could leave this blank, then the authentication chain would be broken. I am oversimplifying OAuth 2.0 in this answer.
You could use Google App Engine, which then provides you with a URL for your deployment. App Engine will work as your orgin and callback.
App Engine User Authentication Options
If your goal is to use Compute Engine, then you will need both a domain name and SSL certificate (Let's Encrypt is free) for your webserver.