So now let's talk about Amazon Cognito.
And the goal of it is to give user an identity
to interact with a web and mobile application.
So these users usually sit outside of our AWS account,
hence the name Cognito,
because it gives an identity to users
that we don't know about yet.
So we have two kind of sub-services within Cognito.
We have the Cognito user pool,
and this provides a sign-in functionality
for app users and has really good integration
with API Gateway and the Application Load Balancer.
And we have the Cognito Identity Pool,
used to be called Federated Identity.
And this is to actually provide temporary AWS credentials
to users that are registered with their application
so that they can access some resources of AWS directly.
And there is a good integration
as we'll see with Cognito User Pools.
So if you are asking yourself,
"Don't we already have users in IAM?"
The answer is yes, you do,
but Cognito is gonna be for your web
and mobile application users,
which sits outside of AWS.
So look for the keyword,
such as hundreds of users, or mobile users,
or authentication with whatever mechanism
such as SAML and so on.
So let's do a deep dive into Cognito User Pool or CUP.
So it's a serverless database of users
for your web and mobile application.
And you can define a simple login,
such as username or email and a password as a combination.
You have password reset feature.
You can have email and phone number verification,
multi-factor authentication for users,
and you can also have integration with,
for example, Facebook for your login,
or Google for your login, and so on.
So this Cognito User Pools,
they integrate with the API Gateway
or the Application Load Balancer.
So if we take the example of the API Gateway,
the user is going to connect to your Cognito User Pool,
retrieve a token, pass this token to the API Gateway,
which is going to verify it, and then if it's good,
it's going to translate it into the user identity,
which will be passed to your lambda function as a backend.
And now your lambda function knows
the user it's dealing with,
and the fact that it has a very specific user
that's been really well authenticated.
Alternatively, you can also do the exact same thing
with your Cognito User Pool
on top of your Application Load Balancer.
So that means that your application
will connect again with your Cognito User Pool,
then pass it on to your Application Load Balancer,
and make sure that there is a true login.
And if it's true,
it will redirect the request to your backend,
and pass in some additional headers
with the identity of the user.
So this really allows you
to have in one place either your API Gateway or your ALB,
the certainty that you can verify the login of your user.
So it's a responsibility that you've moved
from your backend to the actual piece
that is going to balance the load for your backend.
So the API Gateway or the ALB.
Okay, the other sub-part of Cognito is
Cognito Identity Pools or Federated Identities.
And it's to get identities for users, but this time,
they don't access our application
through the API Gateway or the Application Load Balancer,
but instead, they're going to directly access
your AWS accounts using temporary AWS credentials.
So the users' source can be, for example,
users that are within Cognito User Pools,
or it can be third party logins,
and then they can access the services
of AWS directly or through the API Gateway.
So the IAM policies applied to the credentials are defined
within the Cognito Identity Pool service already.
And they can be customized
based on the user ID for fine grain control.
And in case you want to have a default IAM role, you can,
so that your guest users or authenticated users
that don't have specific roles defined to them
will inherit this defined IAM role.
So a diagram will surely help you
to understand what identity pools are.
So let's say your web and mobile applications
want to have direct access
into an S3 bucket or DynamoDB table.
So we're going to have Cognito Identity Pools for this.
So the web and mobile application is
going to log in and get a token out of it.
So it could be a login against Cognito User Pools,
or social identity provider,
or SAML, or open ID connect and so on.
And then it's going to take this token
and pass it on to the Cognito Identity Pool service
to exchange this token for temporary AWS credentials.
And to do so,
the Cognito Identity Pool is first going to evaluate
whether or not the token passed is being correct,
meaning the login is valid.
And the second thing it's going to do is
to craft this IAM policy that is specific to that user.
So these credentials now will,
thanks to this very temporary credentials
with associated IAM policy,
will be able to access AWS on your, for example,
your S3 bucket, or your DynamoDB table,
without going through an API Gateway
or an Application Load Balancer.
And this enables for you a use case
where you can do row level security in DynamoDB.
So you would, for example,
have this policy coming out of the Cognito Identity Pools.
And the idea is that in it, you have a condition,
and this condition is saying
that the leading key for DynamoDB
must be equal to the Cognito identity user ID.
And therefore, what's going to happen is
that the user with this policy cannot read
and write all the items in your DynamoDB table,
that would be too much power,
but instead they can only deal with the items
that they have access to through this condition.
So I understand that Cognito is a very complicated service.
Thankfully, you just need to know
at a high level what it means.
So it means that you can create a user base
for your web and mobile application.
It means you can enable row level security in DynamoDB,
for example, to get fine grain access.
And finally, remember this integration
between Cognito User Pools
and your API Gateway or your Application Load Balancer.
Okay, that's it.
I hope you liked it.
And I will see you in the next lecture.