AWS Cognito User vs Identity Pools

Cognito providing an authentication and authorization solution with fully managed, scalable, and cost-effective sign-up/sign-in service, but unfortunately not straight forward to implement. One of the reasons it’s hard to learn because Cognito is comprised of two services — User Pools and Identity Pools (Federated Identities) — they are similar on the surface but different under the hood. These two services solve the same problem but do so in very different ways. They can also be used separately or together, providing both flexibility and a source of confusion at first.

6 min readMay 7, 2020

TL;DR; The Cognito User Pool stores all your users which then plugs into your Cognito Identity Pool which can give your users access to your AWS services.

Before we dive into the explanation, I think we first need to explain two core security concepts: authentication vs. authorization and identity providers, which sometimes bring confusion even for senior developers.

What Is Authentication?

Authentication is the act of validating that users are who they claim to be. Passwords are the most common authentication factor — if a user enters the correct password, the system assumes the identity is valid and grants access.

What Is Authorization?

Authorization in system security is the process of giving the user permission to access a specific resource or function. This term is often used interchangeably with access control or client privilege.

Authentication vs. Authorization

Let’s use an analogy to outline the differences. If you need to enter a house and the door is locked, you need a set of keys to open it. Unlocking the door with the correct key and gaining access to the house verifies you have the right to enter. This process is authentication. The lock on the door only grants access to someone with the correct key, in much the same way that a system only grants access to users that have the correct credentials.

However, once you have entered the house, you may not have the owner’s permission to access certain areas or appliances. Imagine that your neighbor has asked you to feed her pets while she is away. In this example, you have the authorization to access the kitchen and open the cupboard storing the pet food. However, you can’t go into your neighbor’s bedroom as she did not explicitly permit you to do so. Even though you had the right to enter the house (authentication), your neighbor only allowed you access to certain areas (authorization).

Identity Providers

An Identity Provider is a service that manages authentication, providing a user login and the ability to verify a user’s identity. AWS Cognito has its own Identity Provider (using User Pools, which are explained below), but it can also integrate with well-established third-party Identity Providers like Facebook and Google. Additionally, Cognito can integrate with any Identity Provider that implements the SAML or OAuth2 protocols.

The process of integrating with a third-party for authentication is called the Federation.

Identity providers handle the storage and authentication of the credentials users use to log in to systems, applications, file servers, and other digital resources. They save users the hassle of creating and remembering new usernames and passwords while sparing website owners the trouble of protecting and storing user credentials. Because IdPs are trusted providers, they eliminate the concern of weak security on the part of third-party applications, adding a second, stronger protection layer between your data and any bad actors.

User Pools vs. Identity Pools — Understanding the Difference.

Let’s use an example to illustrate the distinction. Say you’re developing a serverless app using Cognito and Lambda, you would have two options:

Using User Pools to manage authentication
You could configure API Gateway to pass through the user’s ID and group membership to your application. This would allow your code to determine if the user has sufficient permissions to access the requested functionality. However, the IAM permissions used to access the underlying AWS resources, like DynamoDB, would come from the Lambda execution role. All users who access your app would be operating under the same IAM role, and it would be up to you to make sure the right users get access to the right resources.
User Pools (by themselves) don’t deal with permissions at the IAM-level. Rather, they provide information like group membership and the user’s ID to your app, so you can deal with authorization yourself.
Using Identity Pools to manage authentication
AWS would assign the user to an IAM role, and you could flow the permissions associated with that role through the application. This would mean, that the user could access AWS Services with her own IAM permissions, rather than the application-wide permissions that come from the Lambda execution role.
Identity Pools are used to assign IAM roles to users who authenticate through a separate Identity Provider. Because these users are assigned an IAM role, they each have their own set of IAM permissions, allowing them to access AWS resources directly.
Identity Pool in the AWS documentation sometimes can be synonymous with Federated Identity, implies this service is designed to integrate with external Identity Providers

The key distinction here is not whether the Identity Provider is internal or external, but rather if an IAM role is assigned to the user after authentication.

Now that we have a better understanding of what differentiates User Pools and Identity Pools, let’s explore how the two services work together.

User Pools + Identity Pools: Using Them Together

As mentioned earlier, the main purpose of an Identity Pool is to map users from an Identity Provider to an IAM role. An Identity Pool doesn’t have its own user directory, it just assigns users from other user directories to an IAM role in your AWS environment. Often, the Identity Provider is an external third-party, but it can also be your app’s own user directory if it’s implemented as a Cognito User Pool. Since a Cognito User Pool is itself an Identity Provider, you can configure your Identity Pool to use your app’s own User Pool as one of its Identity Providers. This gives you the ability to authenticate users with your User Pool and assign them an IAM role using an Identity Pool.

A similar source of confusion is caused by the fact that you can integrate external social providers like Facebook and Google with User Pools directly, without using Federated Identities at all. Using this approach, users can sign up and sign in to your app with their Facebook login, but they never get assigned an IAM role. Instead, the User Pool service automatically assigns these users to a Facebook group and then maps the attributes of their Facebook profile (e.g. name, email, location) to the user attributes you’ve defined in your User Pool.

User Pools or Identity Pools or Both: Which Approach Is Best?

Cognito provides a great deal of flexibility when securing applications. This allows Cognito to be used more broadly, but it also means there are more moving parts to understand.

Below are three questions you should ask when designing your Cognito architecture.

You want to manage security at the IAM level
If you have important AWS resources whose access can easily be segregated using IAM permissions, then consider using Identity Pools. For example, if you store confidential information in S3, and each bucket stores information for a different department, then it might make sense to use Identity Pools to let AWS manage access to those buckets for you via IAM.
If, on the other hand, most of the information your app is managing resides in a Postgres database, then IAM permissions won’t help you much, as they don’t provide row- or column-level granularity within the database — only your application code can do that.
Consider the trade-off between complexity and security
The more services you use, the more complex the development will be. If you can get away with using a User Pool with no third-party integration, you should do it, as this is the simplest option.
However, if you’re dealing with highly confidential financial data that needs to be securely accessed by multiple external partners, then you should manage access at the application-level AND the IAM-level as a second layer of defense, and this would require User Pools, Federated Identities, and highly granular IAM permissions.
Determine whether your application needs to integrate with third-party Identity Providers
If your app is a small, internal business application, you likely don’t need third-party integration. Your employees will probably be fine managing stand-alone logins for your app.
If, on the other hand, your app is a public, consumer-facing website that promotes self-registration, then giving users the ability to register with an existing social account is a must-have, as it will lead to more sign-ups.

Resources: