In Amazon Cognito, what is the difference between a user pool and an identity pool, and what does each one hand back to the client at the end of a successful sign-in?
answer
- one is a directory, one is a broker
- one returns JWTs, one returns AWS keys
- only one of them authenticates anybody
- IAM roles appear on exactly one side
- chained: token in, credentials out
basics
~20 sA Cognito user pool is the user directory: it authenticates people and returns JWTs. An identity pool is a credential broker: it takes a token you already have and exchanges it for temporary AWS credentials tied to an IAM role. Many apps use both, and some use only one.
solid answer
~50 sThey solve two different problems and are frequently confused because they share a console. A **user pool** is a managed user directory — sign-up, sign-in, MFA, password policies, a hosted UI, and federation to Google, Apple or a SAML IdP. It authenticates a person and hands back ID, access and refresh tokens. Your application, not AWS, is the audience for those tokens. An **identity pool** authenticates nobody. It accepts a token that some trusted provider already issued — a user pool token, a Google token, a raw OIDC or SAML assertion — assigns the caller an identity ID, and returns short-lived AWS credentials (an access key, secret key and session token) for an IAM role. That is the only thing it produces. So: user pool for logging users into *your* app; identity pool when a client must call *AWS APIs* directly. If nothing in your architecture calls AWS from the client, you likely need no identity pool at all.
go deeper
Be able to state the split in one line: user pool authenticates users and returns JWTs, identity pool exchanges a token for temporary AWS credentials.
Explain the chained flow end to end and say which artifact crosses each hop, and name the three common architectures — user pool only, identity pool only, and both together.
Argue whether the client should hold AWS credentials at all, and show that an identity pool's blast radius is decided entirely by the IAM role policies and trust policy behind it.
Own the customer-identity decision at product scale: build on a user pool or point an identity pool at an IdP you already run, what migration between them costs, and where entitlement decisions live once identity is federated.
## Two services under one name Amazon Cognito is really two products. They are configured in the same console, they interoperate, and they are routinely described together — which is exactly why interviewers ask candidates to separate them. **User pools** are a hosted user directory with an authentication front end. A user pool stores user records with standard and custom attributes, enforces a password policy, handles sign-up and email or SMS verification, supports MFA, offers a hosted sign-in UI on a Cognito domain, and can federate to external identity providers so "Sign in with Google" or a corporate SAML IdP produces a user in your pool. The product of a successful user pool authentication is a set of JWTs: an ID token, an access token and a refresh token. Those tokens are consumed by your application and your APIs. Nothing about them grants access to AWS itself. **Identity pools** (historically "Cognito federated identities") do one job: turn a proof of identity into temporary AWS credentials. An identity pool is configured with a list of trusted providers — one or more Cognito user pools, social providers, an OIDC provider, a SAML provider, or a developer-authenticated backend of yours — plus an IAM role for authenticated callers and, optionally, one for unauthenticated guests. A client calls `GetId` to obtain an identity ID, then `GetCredentialsForIdentity`, and receives an access key, a secret key and a session token scoped to that role. Those credentials are what an AWS SDK on the device signs requests with. ## The shapes that actually appear **User pool only.** A web or mobile app signs users in, receives JWTs, and calls your own backend with the access token. Your backend talks to AWS using its own execution role. This is the most common architecture, and it needs no identity pool. **Identity pool only.** A client already authenticates somewhere else — your own login service, or a social provider directly — and simply needs AWS credentials. Guest access to a public read-only bucket is the classic unauthenticated-role case. **Both, chained.** The user signs in to the user pool, receives an ID token, hands that ID token to the identity pool, and gets AWS credentials whose IAM role you scope per user. This is the shape people mean when they say "Cognito lets my app upload to S3". ``` user --sign in--> user pool --ID token--> identity pool --AWS creds--> S3 / DynamoDB ``` ## Why the distinction is load-bearing The two products fail differently and are secured differently. A user pool's security surface is the app client configuration, the allowed callback URLs, the enabled auth flows, the token lifetimes, and whether your API actually verifies tokens. Its failure modes are authentication failures: a user cannot sign in, a federated attribute did not map, a token was accepted that should not have been. An identity pool's security surface is IAM. What the caller can do is entirely determined by the authenticated and unauthenticated role policies and by the role's trust policy, which must trust `cognito-identity.amazonaws.com` and condition on the identity pool ID through the `cognito-identity.amazonaws.com:aud` key. Its failure modes are authorization failures: `AccessDenied` from an AWS API because the role policy is too narrow, or — far worse — every signed-in user able to read every other user's objects because the policy was written with a wildcard resource. Identity pools can also map different providers or different user pool groups to different IAM roles, either by a rules-based mapping on a token claim or by letting a `cognito:preferred_role` claim choose. That is genuinely useful and genuinely easy to misconfigure. ## Choosing Ask one question: does code running on the end user's device need to call an AWS API directly? If yes, you need an identity pool, and you must accept that the client holds real AWS credentials for as long as they are valid. If no — every AWS call originates in your own compute, which already has a role — an identity pool adds a service, a set of IAM roles and an attack surface for nothing. A second question distinguishes the user pool: do you want AWS to own your user directory, passwords, MFA and federation? If you already run an identity provider, a user pool may be redundant, and you can point an identity pool straight at your existing OIDC or SAML provider. One more separation worth stating out loud in an interview: neither product is for your *employees'* access to the AWS console and CLI. That is workforce identity, and it belongs to a different AWS service. Cognito is the customer-facing side.
- Can an identity pool be used without a user pool at all?Yes. An identity pool trusts providers, and a Cognito user pool is only one of the options — it can equally trust Google, Apple, an arbitrary OIDC provider, a SAML IdP, or your own backend through developer-authenticated identities. It can also issue credentials for an unauthenticated role with no provider at all, which is how guest access to public resources is built.
- How does an identity pool decide which IAM role a given user gets?By default it uses the pool's authenticated or unauthenticated role. Beyond that you can configure role mapping per provider: rules that match a claim in the incoming token, or letting a claim choose from the roles the token declares. Group membership in a linked user pool can drive this, which is how admins and ordinary users end up on different policies.
- A team asks whether Cognito can give their employees CLI access to production accounts. What do you say?That is workforce identity, not customer identity, and it is the wrong service. Cognito user pools are built for your application's end users. Human access to AWS accounts and the CLI is handled by AWS's workforce identity service with permission sets, so the answer is to route that request there rather than modelling staff as app users.
The user pool is the front desk that checks your ID and issues a badge. The identity pool is the machine that trades a valid badge for a temporary key card to specific rooms in the building.
saying these in an interview costs you the question
- Says a user pool issues AWS credentials
- Thinks an identity pool authenticates users itself
- Believes every Cognito app needs both pools
- Assumes identity pool permissions come from the user pool, not IAM
- Uses Cognito to give employees AWS console access