Why AWS Cognito has two places to federate Identity Providers? I think Identity Pool is supposed to be federated with identity providers and wonder why User P
User Pool
User pools are for authentication (identity verification). With a user pool, your app users can sign in through the user pool (which is essentially a user directory in Amazon Cognito) or federate through a third-party identity provider (IdP), for example social identity providers like Google, Facebook, Amazon, or Apple, and through SAML identity providers.
After successfully authenticating a user, Amazon Cognito issues JSON web tokens (JWT) that you can use to secure and authorize access to your own APIs, or exchange for AWS credentials (here is where Identity Pool comes into play).
Use a user pool when you need to:
- Design sign-up and sign-in webpages for your app.
- Access and manage user data.
- Track user device, location, and IP address, and adapt to sign-in requests of different risk levels.
- Use a custom authentication flow for your app.
Identity Pool
Identity pools are for authorization (access control). With an identity pool, you can obtain temporary, limited-privilege AWS credentials to access other AWS services.
Use an identity pool when you need to:
- Give your users access to AWS resources, such as an Amazon Simple Storage Service (Amazon S3) bucket or an Amazon DynamoDB table.
- Generate temporary AWS credentials for unauthenticated users (User Pools support anonymous guest users).
Identity pools provide AWS credentials to grant your users access to other AWS services. 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.
Sources:
https://aws.amazon.com/premiumsupport/knowledge-center/cognito-user-pools-identity-pools/
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html
The Main Difference is how users are saved and what permissions are granted once they signin with idp's using user pool vs identity pool.
So, Federation through User Pool (by themselves) don’t deal with permissions at the IAM-level which doesn't allow for a much more granular set of permissions, with respect to AWS services.
However Identity Pools creates a user from an Identity Provider with unique identities such as an IAM role, they essentially allow you to delegate authorization for AWS resources to AWS itself.
Refer here for scenarios!!
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. Again, 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.
Hope it Helps.