The course is part of this learning path
This course explores Amazon Cognito and how it can be used to manage authentication and authorization to your apps. We'll start with a general overview of Amazon Cognito and when to use it. Then we move on to user pools and identity pools. We round off the course by looking at how Amazon Cognito can be integrated with mobile and web apps and how to sync your app's user data across various platforms.
Learning Objectives
- Create your own authentication mechanisms using Amazon Cognito
- Create your own customized UI for user sign in
- Create a secure user directory for all your applications and users
Intended Audience
This course is intended for anyone who is trying to understand what mechanisms are available for user authentication within AWS and specifically, those who want to use third-party identity providers, such as Apple, Facebook, Google, and Amazon.
Prerequisites
- A decent understanding of cloud computing and cloud architectures, specifically with Amazon Web Services
- Familiarity with basic security terminology, IAM, user authentication, and federation
- It is helpful to know about Active Directory and other AD type services
The Amazon Cognito Identity pools - also known as Federated Identities, Helps to provide temporary access AWS Credentials for your users or guests that need access to AWS services.
Identity pools can work in tandem with Amazon Cognito user pools, allowing your users to operate and access whatever specific feature they need from AWS.
Additionally, just like with User pools, you can federate with public providers such as Amazon, Facebook, and Google.
The Identity pools help to define two types of identities - Authenticated identities and unauthenticated identities.
Each identity within your identity pool has to be in one of these two states.
To gain the authenticated state, a user must be authenticated by a public login provider. This can be your Amazon Cognito user pool from early, or can also be any of those other public ID providers like Amazon, Apple, Facebook, Google, SAML, and even an Open ID connect provider.
You can also have Unauthenticated identities. This can be useful for a number of reasons, but the primary ones might be for allowing users to see various AWS resources before they are completely logged in. Giving them some visibility into dashboards for example - so they could at a glance see if something was wrong.
You can also use Unauthenticated identities to act as a sort of guest pass for when you want people to have some access to basic services and later prompting them to sign in or sign up.
Each type of identity has a role that goes along with it. Roles have policies attached to them, that set the permissions for what that user is allowed to do within AWS. Roles help to define boundaries and allow you to explicitly state what an authenticated or unauthorized user can, and can not, modify or even see.
If you need a refresher on roles beyond what I’ve just described, please take a look over here for an in-depth look at this feature:
The big thing I want you to think about when differentiating between Identity pools and User pools is that Identity pools are used for authentication and access control ( specifically for AWS services). While user pools are designed for sign-up and sign-in type operations.
William Meadows is a passionately curious human currently living in the Bay Area in California. His career has included working with lasers, teaching teenagers how to code, and creating classes about cloud technology that are taught all over the world. His dedication to completing goals and helping others is what brings meaning to his life. In his free time, he enjoys reading Reddit, playing video games, and writing books.