Amazon Cognito is an AWS service that lets you easily add users’ management to web and mobile apps. It supports social identity providers, such as Facebook, Google and enterprise identity providers via SAML 2.0.
A powerful service.
At first, hard to understand.
One of the things that generate the biggest confusion is the fact that Amazon Cognito comes with two main components:
- Amazon Cognito User Pools
- Amazon Cognito Identity Pools (aka Federated Identities)
This is the first blocker because, in the common language, users and identities are almost the same things.
In this brief story, we will try to clarify real differences and what scenarios can be solved using one of these components or combining the two.
Cognito User Pool
According to the AWS official documentation:
A user pool is a user directory in Amazon Cognito. With a user pool, your users can sign in to your web or mobile app through Amazon Cognito […]
This means an anonymous user of our application (e.g. a mobile or a Single Page Application) can fill a registration form and then become a registered user. The chosen credentials (i.e. username and password) will be safely stored into Cognito User Pool.
In this case, Amazon Cognito acts as an Identity Provider (IdP).
When this registered user wants to log in, the User Pool will be used as the source of truth to assess the authenticity of provided credentials; if valid, a JSON Web Token (JWT) will be returned (click here, if you want to know more about JWT).
Fig. 1 – During a user’s login, Cognito User Pool will handle the credential’s verification process, if valid, a JWT will be issued. This token could be eventually used to invoke protected APIs.
Eventually, if we have a protected API (e.g. GET /orders/42) this token can be used to authenticate requests (fig.2) through the Authorization header.
If this API has been created using Amazon API Gateway, there’s the opportunity to easily protect it through the Cognito User Pool. In this scenario, API Gateway will ask Amazon Cognito User Pool to validate that token; if successful the backend Lambda function will be invoked.
Fig.2 – API Gateway can be integrated natively with Cognito User Pool to validate the provided JWT.
Easy like Sunday morning.
But what if our application needs to interact directly with DynamoDB (fig.3)?
Cognito Identity Pool
Usually, REST APIs are protected through the use of a token – e.g. a JSON Web Token (JWT) – and that’s why Amazon API Gateway with the help of Cognito User Pool supports this scenario natively.
Fig.3 – Sometimes your client application may want to access directly to an AWS service (e.g. DynamoDB) without the API Gateway as a proxy. Will the JWT still be useful?
Alas, the vast majority of AWS resources, doesn’t support a JWT as a means of authentication! For instance, if our application would read the order item 42 directly from DynamoDB, we need an IAM Role that has the permission to read data from the Orders table.
And here it comes Cognito Identity Pool:
Identity pools provide AWS credentials to grant your users access to other AWS services.
Here, “your users” are the users registered into our Cognito User Pool.
To enable users in your user pool to access AWS resources, you can configure an identity pool to exchange user pool tokens for AWS credentials.
To enable these users to access directly to DynamoDB and read the given order, we can’t use JWT straight; but we have to use Cognito Identity Pool to trade JWT with an access key and secret key (fig.4).
Fig.4
Each couple of keys has an IAM role associated with the right set of permission.
Here, thanks to the Identity Pool, Amazon Cognito acts as an Identity Broker.
Some caveats
In a simple scenario everything can be summarised in a general rule:
If our application needs to access an API Gateway endpoint then, Cognito User Pool is sufficient.
If our application needs to talk directly with an AWS service (DynamoDB, S3, …) we need Amazon Cognito Identity Pool too.
Unlikely, things are not necessarily black or white and real life has many nuances. For instance, our application could have users registered on a third-party Identity Provider and, in this case, we would use Cognito Identity Pool but not Cognito User Pool (more info in the Further reading section).
Conclusion
Even the most mundane things, if not well understood, will seem difficult. Amazon Cognito is no exception. I hope this story helps those who did not have a very clear understanding of the topic.
Top comments (0)