👥 Federated Authentication with Cognito


Hey Reader 👋🏽

Federated Authentication lets users sign in to your app using their existing accounts - most prominently Google!

This approach eliminates the need to create and remember new credentials (which most users are very happy for! ✨), improving user experience and likely increasing conversion rates. 📈

With OAuth 2.0 and Google as an identity provider, we can have secure authentication while Amazon Cognito handles identity management, user pools, and integration with other AWS services.

Using Cognito with Google authentication gives you the best of both worlds: Google’s widespread adoption and Cognito’s powerful identity management features, including user attributes, security policies, and AWS service integration.

We've built a small app powered by SST which showcases how easy it is to set this up! Apart from providing your Google OAuth client details and the name of your Cognito domain, you don’t need anything else to run a ready-to-use solution on your own account.

Let's go through the steps one-by-one!

Setting Up Google as a Federated Identity Provider

Before we start coding, we need to set up Google to use it as an identity provider for our application. Even if you’re new to authentication, this is quite simple to do.

What steps do we need to follow?

  • Create a consent screen: This will be shown to the user on Google after they click the Login with Google button.
  • Create an OAuth Client: This client will be used to establish the connection between Cognito and Google. We will receive a client ID and a client secret.
  • Add whitelisted redirect URLs: This is necessary to inform Google which targets it is allowed to redirect to.

Creating a Consent Screen

Before we can create an OAuth Client ID, we must set up our consent screen. This screen will appear when the user clicks the Google button to continue signing up.

We only need to provide a small amount of information here. This includes the name of our application, a support email that users can contact for issues, and a whitelisted domain.

Creating an OAuth Client

Next, we can move on to creating an OAuth Client.

Let’s choose Web Application and add http://localhost as a valid JavaScript origin.

Google needs to know where it is allowed to redirect, as these targets will receive the authorization code used to get a valid token for the logged-in user. In a nutshell: the user will be redirected to this URL after the authentication flow has finished.

When using the hosted UI version of Cognito, the URL will follow this pattern:

https://$POOL_DOMAIN.auth.$REGION.amazoncognito.com/oauth2/idpresponse

The $REGION will be the AWS region where we’ll deploy Cognito. In our example application, we’re using eu-west-1, but you can choose whichever region you prefer.

You can also choose the pool domain yourself. It needs to be globally unique, so pick something that’s unlikely to be taken.

Let’s finish the creation of the client.

After creating our client, we’ll receive a OAuth Client ID that should look like this: m9x[...]i9o.apps.googleusercontent.com

When clicking on our new client, you’ll also be able to get the secret for our client.

Don’t worry about copying both values right now. You can retrieve them later, even if you leave the page and return.

Amazon Cognito Setup

The manual setup is now complete. Let’s move on to AWS and create everything else using Infrastructure as Code with SST and Pulumi.

What do we need to create?

  • Cognito User Pool: Holds and manages user identities, including registration and sign-in.
  • User Pool Domain: Provides a unique URL for accessing Cognito’s hosted authentication UI.
  • Google as an Identity Provider: Enables users to sign in with their Google accounts via OAuth.
  • User Pool Client: Represents the application that will use the user pool for authentication, managing tokens and authentication flows.
  • Next.js Frontend: A test application to interact with the authentication flow.

As you see, there are only a few AWS resources necessary - all of them are pay-as-you-go with a very generous free tier on the monthly active users at Cognito! 💸

If you're interested in the details, you can find the detailed description - including code snippets - at our full blog post. If you directly want to jump in, please check out the provided repository to deploy it straight into your own account! 🏗️ (Please don't forget to set your Google OAuth client details and your desired Cognito pool domain in the environment file! 😌)

Thanks for reading & enjoy playing around with this simple two-click sign-up and one-click sign-in method! 🔐

Tobias Schmidt & Sandro Volpicella & from AWS Fundamentals
Cloud Engineers • Fullstack Developers • Educators

You're receiving this email because you're part of our awesome community!

If you'd prefer not to receive updates, you can easily unsubscribe anytime by clicking here: Unsubscribe

Our address: Dr.-Otto-Bößner-Weg 7a, Ottobrunn, Bavaria 85521

AWS for the Real World

Join our community of over 9,300 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.

Read more from AWS for the Real World

Hey Reader 👋🏽 This issue will be about a recent real-world experience that just went off right with the new year! 🎉 Once upon a time... 🦄 It all started in September 2024 where Edgio, the main CDN provider we used for one of my large enterprise projects, filed for bankruptcy. Edgio was natively integrated into Azure, allowing you to use it without leaving the Azure ecosystem. It also featured a powerful rules engine (allowing for all kinds of conditions, redirects and rewrites) and didn’t...

⌛ Reading time: 13 minutes 🎓 Main Learning: How to Run Apps on Fargate via ECS 👾 GitHub Repository ✍️ Read the Full Post Online 🔗 Hey Reader 👋🏽 When building applications on AWS, we need to run our code somewhere: a computation service. There are a lot of well-known and mature computation services on AWS. You’ll often find Lambda as the primary choice, as it’s where you don’t need to manage any infrastructure. You only need to bring your code - it’s Serverless ⚡️. However, more options can be...

⌛ Reading time: 10 minutes 🎓 Main Learning: Running Postgres on Aurora DSQL with Drizzle 👾 GitHub Repository ✍️ Read the Full Post Online 🔗 Hey Reader 👋🏽 With re:Invent 2024, AWS finally came up with an answer to what many people (including us) asked for years: "What if there were something like DynamoDB but for SQL?" With Amazon Aurora DSQL, this is finally possible. It’s not just a “scales-to-zero” solution like Aurora Serverless V2. It is a true distributed, serverless, pay-per-use...