Amazon Cognito User Pools and Identity Pools – SAP-C02 Study Guide

Purpose of This Lesson

Amazon Cognito provides identity capabilities for customer-facing web, mobile, and client applications. The key distinction is between:

• Cognito user pools, which authenticate users and issue tokens.
• Cognito identity pools, which exchange authenticated or guest identities for temporary AWS credentials.

Understanding which pool is needed—and whether an application needs AWS credentials at all—is a frequent AWS certification exam decision point.

Key Concepts

Cognito User Pools: User Authentication

A user pool is a managed user directory for application users. It supports common identity workflows such as:

• User registration and sign-in
• Password management and account recovery
• User attributes and profile management
• Multi-factor authentication (MFA)
• Adaptive and custom authentication flows
• Federation with external identity providers (IdPs)

External IdPs can include social providers such as Google, Apple, Amazon, or Facebook, as well as enterprise identity providers using supported federation protocols. Cognito can act as an identity broker, allowing users to authenticate through an existing external account.

After successful authentication, the user pool issues JSON Web Tokens (JWTs), typically including:

• ID token: Claims about the authenticated user, intended for the client application.
• Access token: Permissions and scopes related to access to user-pool-protected resources.
• Refresh token: Used to obtain new tokens after the access token expires, subject to the configured token lifetime and session rules.

A user pool is therefore primarily an authentication service. It answers: Who is this user?

It does not directly provide temporary IAM credentials for calling AWS APIs.

Protecting APIs with User-Pool Tokens

A client can include a user-pool JWT when calling an application API. The API layer can validate the token and enforce access controls before forwarding the request to the backend.

Common integration patterns include:

• Amazon API Gateway using a Cognito user pool authorizer or JWT authorizer, depending on the API type and configuration.
• A Lambda authorizer that performs custom token validation and authorization logic.
• AWS AppSync using Cognito-based authentication for GraphQL APIs.
• Application code validating claims, groups, scopes, or other token attributes.

Authentication alone does not guarantee that every authenticated user can perform every operation. Authorization should be based on claims, scopes, groups, application permissions, or backend policy checks as appropriate.

Cognito Identity Pools: Temporary AWS Credentials

An identity pool provides temporary, limited-privilege AWS credentials to client applications. It integrates with AWS Security Token Service (AWS STS) and returns credentials associated with an IAM role.

Identity pools can use identities from several sources, including:

• Cognito user pools
• Social identity providers
• SAML or other supported federated identities
• Unauthenticated or guest users, when explicitly enabled

The IAM role determines what the client can do in AWS. Its permissions policy might allow narrowly scoped access to services such as Amazon S3, Amazon DynamoDB, or Amazon Kinesis.

An identity pool answers: What can this client access in AWS?

The credentials are temporary rather than long-lived access keys. Their permissions and lifetime should be constrained according to the application’s requirements.

Using User Pools and Identity Pools Together

A common architecture combines both pool types:

1. The client authenticates against a Cognito user pool or a federated IdP.
2. The user pool returns JWTs.
3. The client presents the authenticated identity to a Cognito identity pool.
4. The identity pool exchanges the identity for temporary AWS credentials through AWS STS.
5. The client uses those credentials to call permitted AWS services directly.

This pattern is useful when a mobile or browser application needs direct, controlled access to AWS resources—for example, uploading objects to an S3 bucket without routing every object through an application server.

However, if the application only needs to call API Gateway or another application endpoint, a user pool may be sufficient. The backend can validate the JWT, and the client does not need AWS credentials.

Authentication Versus Authorization

The distinction is important:

Requirement	Appropriate Cognito capability	Result
Register and authenticate application users	User pool	User-pool tokens, including JWTs
Let users sign in with an external IdP	User pool or supported identity-pool federation, depending on the design	Federated identity
Protect an API using user identity and claims	User-pool JWT with an API authorizer or custom validation	Authenticated API request
Allow a client to call AWS services directly	Identity pool	Temporary IAM credentials from AWS STS
Allow restricted guest access to AWS resources	Identity pool with unauthenticated role enabled	Temporary credentials for the guest role
Define AWS permissions	IAM role assumed through the identity pool	Permissions policy controls allowed actions

Exam-Relevant Takeaways

• User pools are user directories and authentication providers. They handle registration, sign-in, MFA, federation, and token issuance.
• Identity pools provide temporary AWS credentials. They use AWS STS and IAM roles to authorize access to AWS services.
• A user pool issues JWTs, not IAM access keys.
• An identity pool can be used with a user pool, but it can also federate identities from supported external providers directly.
• Identity pools can support unauthenticated guest access if the architecture explicitly enables it and assigns an appropriate guest IAM role.
• Do not give clients broad IAM permissions. Use least-privilege role policies and resource-level restrictions where supported.
• If a client only needs to access an API, use token-based API authorization rather than introducing an identity pool unnecessarily.
• If a client needs direct access to S3, DynamoDB, or another AWS service, an identity pool may be appropriate.
• The presence of a valid JWT proves authentication and token validity; application-specific authorization still needs to be designed.

Architecture Decision Guide

Application requirement	Recommended design	Why
Web or mobile users need sign-up and sign-in	Cognito user pool	Provides a managed application user directory and authentication flows
Users should sign in with Google, Apple, or another external provider	User pool federation	Cognito brokers authentication and issues application tokens
API Gateway must accept authenticated application requests	User-pool JWT plus API authorization	The API can validate token claims without granting AWS credentials to the client
Mobile users need direct, scoped S3 uploads	User pool plus identity pool, or another supported identity source plus identity pool	The client receives temporary credentials tied to an IAM role
Anonymous users need limited access to AWS resources	Identity pool with an unauthenticated role	Provides temporary credentials with a separate guest permission set
The backend alone accesses AWS services	User pool for client authentication; backend IAM role for AWS access	The client does not need direct AWS credentials
Different user categories require different AWS permissions	Identity pool role mapping and IAM policies	Authenticated identities can receive roles based on claims or rules

Common Exam Traps

• Confusing JWTs with AWS credentials: A user-pool JWT authenticates an application user. It does not authorize direct calls to AWS APIs in the same way as temporary IAM credentials.
• Assuming every Cognito design needs both pool types: Use an identity pool only when the client requires temporary credentials for AWS services.
• Treating authentication as complete authorization: A valid token does not automatically mean the user can perform every business operation.
• Using permanent access keys in a mobile application: Prefer temporary credentials from an identity pool when direct AWS access is required.
• Granting broad permissions to an identity-pool role: Guest and authenticated roles must be tightly scoped, particularly for S3 prefixes, DynamoDB actions, and write operations.
• Assuming identity pools replace API authorization: If clients call an API, the API still needs token validation and application-level authorization.
• Ignoring guest access risk: Enabling unauthenticated identities means anyone who can access the client flow may obtain the guest role’s permissions.
• Putting sensitive authorization logic only in client code: Client-side checks improve user experience but are not a security boundary. Enforce critical permissions at the API or service layer.

Real-World Engineer Notes

• Design the trust boundary explicitly. A browser or mobile client should receive only the access it needs, and high-value operations should generally pass through a controlled backend.
• Use separate IAM roles for authenticated and unauthenticated identities. Avoid sharing a role between users and guests.
• Scope S3 permissions to specific buckets and key prefixes where possible. For example, a user might be allowed to write only under a prefix associated with that user or tenant.
• Use token claims, groups, and scopes as inputs to authorization, but validate important business rules against trusted server-side data.
• Consider token expiration and refresh behavior when designing offline-capable mobile applications.
• For API Gateway integrations, choose the authorizer mechanism that matches the API type and validation requirements. A Lambda authorizer is useful when authorization requires custom logic, while a managed JWT or Cognito authorizer can reduce operational complexity for standard token validation.
• Monitor authentication failures, unusual federation activity, and unauthorized AWS API calls using appropriate logging and monitoring services.

Quick Reference Summary

• User pool: Managed application user directory; sign-up, sign-in, MFA, federation, and JWT issuance.
• JWT: Token used to represent an authenticated application identity and associated claims.
• Identity pool: Federation service that provides temporary AWS credentials.
• AWS STS: Service used to issue short-lived credentials assumed through an IAM role.
• IAM role: Defines what AWS actions an identity-pool client may perform.
• Use only a user pool: When clients need to authenticate and call an application API.
• Use an identity pool: When clients need direct access to AWS services with temporary credentials.
• Use both: When users authenticate through a user pool and then need scoped direct AWS access.

Flashcards

1. What is the primary purpose of a Cognito user pool?

To provide a managed directory and authentication service for application users.

2. What does a Cognito user pool issue after authentication?

JWTs, including ID, access, and refresh tokens.

3. Does a user pool issue temporary IAM credentials?

No. User pools issue application authentication tokens, not AWS credentials.

4. What is the primary purpose of a Cognito identity pool?

To provide temporary, limited-privilege AWS credentials to authenticated or guest clients.

5. Which AWS service issues the temporary credentials used by an identity pool?

AWS Security Token Service (AWS STS).

6. What determines the AWS permissions granted through an identity pool?

The IAM role assumed by the identity and the role’s permissions policies.

7. Can an identity pool be used without a Cognito user pool?

Yes. It can federate supported external identities directly and can also support unauthenticated guest identities when enabled.

8. When is a user pool alone usually sufficient?

When a client needs to authenticate users and call a protected application API, but does not need direct AWS service access.

9. When would an application use both pool types?

When users authenticate through a user pool and then need temporary credentials to access AWS services directly.

10. What is a common security risk with unauthenticated identity-pool access?

Granting excessive permissions to the guest IAM role, allowing anonymous clients to access or modify sensitive resources.

Practice Questions

Question 1

A company is building a mobile application. Users must register, sign in with Google, and call an API Gateway REST API. The backend performs all S3 and DynamoDB operations. The security team does not want AWS credentials distributed to mobile clients. Which design is most appropriate?

A. Use an identity pool and give the mobile application an IAM role with S3 and DynamoDB permissions.

B. Use a Cognito user pool federated with Google and protect API Gateway with a user-pool authorizer.

C. Create IAM users for each mobile user and embed their access keys in the application.

D. Enable unauthenticated identities in an identity pool and use the guest role for API access.

Correct answer: B

The users need application authentication and API authorization, which a federated user pool and API authorizer provide. Since the backend—not the mobile client—accesses S3 and DynamoDB, an identity pool is unnecessary and distributing IAM credentials would be inappropriate.

Question 2

A browser application allows authenticated users to upload files directly to Amazon S3. Each user must be restricted to a specific prefix in the bucket. Which solution best meets the requirement?

A. Use a Cognito user pool only and place the user’s JWT directly in the S3 request.

B. Use a Cognito identity pool with authenticated identities mapped to an IAM role that restricts S3 access to the required prefix.

C. Create a long-lived IAM access key for every application user.

D. Make the S3 bucket public and validate users in JavaScript.

Correct answer: B

Direct S3 access requires AWS credentials. An identity pool can exchange the user’s authenticated identity for temporary credentials associated with an IAM role. The role and bucket policy can restrict access to the user’s permitted prefix.

Question 3

An application has a Cognito user pool. A user presents a valid access token to an API, but the user attempts an administrative operation that should be limited to administrators. What additional control is required?

A. Disable refresh tokens for all users.

B. Add authorization logic based on claims, groups, scopes, or backend permissions.

C. Replace the user pool with an identity pool.

D. Convert the access token into a permanent IAM user access key.

Correct answer: B

Token validity establishes authentication, but authorization must determine whether the user is allowed to perform the requested operation. The API or backend should enforce administrator permissions using appropriate claims and server-side rules.

Question 4

A public mobile application must allow unauthenticated users to download a limited set of public catalog data from DynamoDB. Authenticated users require additional access. Which Cognito capability supports separate AWS permissions for these two cases?

A. A user pool with a single shared JWT.

B. An identity pool with separate unauthenticated and authenticated IAM roles.

C. An IAM user for each anonymous session.

D. An API Gateway resource policy that grants all clients full DynamoDB access.

Correct answer: B

An identity pool can issue temporary credentials for both guest and authenticated identities. Separate IAM roles allow the guest role to receive only the limited read permissions while authenticated users receive the additional access required by the application.