Amazon Cognito User Pool vs Identity Pool for aws-auth

Quick answer

Choose a Cognito user pool when you need sign-up, sign-in, federation, user profiles, and JWTs for your app or API. Add a Cognito identity pool only when the browser or mobile client must exchange identity evidence for temporary AWS credentials and call services such as S3 directly.

Some apps use both: user pool for authentication, then identity pool for scoped AWS credentials. The two pool types are complementary, not interchangeable.

Decision table

Requirement	User pool	Identity pool	Both
Sign-up, sign-in, managed login	Yes	No	User pool handles it
Issue OIDC-compatible JWTs	Yes	No	User pool handles it
Call only your backend API	Usually sufficient	Usually unnecessary	Rarely needed for this alone
Client uploads directly to S3	Authentication only	Vends temporary AWS credentials	Common pattern
Social or enterprise federation	Federates into user directory and tokens	Can accept supported providers	Depends on desired session path
Fine-grained AWS permissions	No AWS credentials by itself	Uses mapped IAM roles	Identity pool plus IAM controls
Guest AWS access	No	Optional unauthenticated identities	Identity-pool decision

If the requirement says “authorize a user to an application object,” that is application authorization. If it says “let this signed-in client call an AWS API,” that is where an identity pool may fit.

Architecture A: user pool and your API

Browser or mobile app -> Cognito user pool -> JWT -> your API authorizer -> backend rules

This is the simpler path when the client calls only your API. Configure a public app client for a SPA or mobile app, use authorization code with PKCE, validate the token at the API boundary, and enforce scopes plus tenant, ownership, and object rules in the backend.

The API authorizer does not replace business authorization. It can establish token validity and selected claims; your application still decides whether this user can perform this action on this resource.

Architecture B: user pool plus identity pool

Client -> user pool sign-in -> user-pool token -> identity pool -> temporary AWS credentials -> scoped AWS service

Use this when direct client access is intentional—for example, a browser uploads to a specific S3 prefix without proxying the file through your API.

The identity pool maps authenticated identity context to an IAM role and obtains temporary credentials. Restrict the role to exact actions and resources. Test that one user’s credentials cannot reach another user’s prefix or tenant data.

Architecture C: identity pool without a user pool

An identity pool can work with supported external identity providers and can optionally support unauthenticated identities. This does not create a Cognito user directory or managed-login experience.

Guest access is a product and security decision, not a harmless default. If enabled, create a distinct, highly restricted unauthenticated role and verify denied paths. Do not reuse the authenticated role.

What the aws-auth skill should ask before acting

1. Does the client need sign-up and sign-in, or only workload credentials?
2. Does the client call your API, AWS services directly, or both?
3. Which identities are authenticated, federated, or guest?
4. Which exact AWS actions and resource ARNs are required?
5. How are users or tenants mapped to resource prefixes and roles?
6. What is the session duration and revocation expectation?
7. Which existing pool, provider, app-client, role-mapping, and IAM settings must be preserved?

Answers should produce an architecture decision before any CLI command.

Full-replacement and ownership warning

An identity-pool role update is not an isolated permission edit. The AWS-owned skill warns that set-identity-pool-roles replaces the roles and role-mapping structure supplied to the operation. Read the current configuration, preserve required mappings, review a full diff, and then write.

IAM roles and trust policies are also outside the narrow Cognito pool decision. Have the IAM owner review least privilege, confused-deputy protections, resource policies, and tenant boundaries.

Verification matrix

Test	Expected result
Valid user-pool token to the intended API	Authorizer accepts; backend still evaluates resource permission
Token with wrong issuer or audience	Denied
Signed-in client requests its permitted S3 prefix	Temporary credentials permit only intended actions
Same client requests another user’s prefix	Denied
Guest requests authenticated resource	Denied
Identity provider or role mapping does not match	No unintended fallback to a broader role
Credentials expire	Client refreshes through the intended identity path or reauthenticates

Use the Cognito auth workflow planner to turn the choice into a review contract. See the aws-auth setup guide before giving an agent write access, and use the OAuth, PKCE, and passkeys guide for the interactive sign-in layer.

Frequently asked questions

What is the difference between a Cognito user pool and identity pool?

A user pool is a user directory and OIDC identity provider that authenticates users and issues JWTs. An identity pool accepts supported identity evidence and vends temporary AWS credentials for scoped access to AWS services.

Does an app with its own backend need an identity pool?

Usually not. If the client signs in and calls only your backend, a user-pool token can be evaluated by the API. Add an identity pool only when the client needs temporary AWS credentials to call AWS services directly.

Can an application use both Cognito pool types?

Yes. A common combined architecture authenticates the user with a user pool, then supplies that token to an identity pool that maps the user to a tightly scoped IAM role.

Does an identity pool replace IAM design?

No. Identity pools depend on IAM roles, trust relationships, role mappings, session context, and resource policies. The returned credentials can do only what those policies allow.

Official sources

• AWS: Amazon Cognito user pools
• AWS: Amazon Cognito identity pools
• AWS: accessing AWS services with an identity pool
• AWS: API Gateway access after sign-in
• AWS-owned aws-auth skill source

Source check: August 9, 2026. Verify supported identity providers, role-mapping behavior, feature plans, API shapes, session settings, IAM guidance, and prices before production use.