This chapter covers Amazon Cognito User Pools and Identity Pools — two distinct but complementary services for authentication and authorization in AWS. Understanding the difference between them is critical for the SAA-C03 exam, as questions frequently test your ability to choose the right pool for a given scenario. Approximately 5-8% of exam questions touch on Cognito or related identity services. We'll dissect how each pool works, when to use which, and common pitfalls that trip up candidates.
Jump to a section
Think of Amazon Cognito User Pools and Identity Pools as a hotel's guest management and access control system. The User Pool is like the hotel's front desk registration. When a guest arrives, they present their ID and credit card, and the front desk creates a record: a room key card that proves their identity (a JWT token). This key card contains the guest's name, room number, and check-out date — it's only about who they are. The front desk can also verify the guest's identity using a third-party ID like a passport (federated identity with Google, Facebook, etc.). Once the guest has their key card, they can access their room (the app's authenticated resources). The Identity Pool, on the other hand, is like the hotel's master key system for staff. A housekeeper might have a master key that opens all rooms on floor 3, but not the executive suite. The Identity Pool takes a verified identity (from the User Pool or an external provider) and exchanges it for a temporary AWS credential (like a master key) that grants access to specific AWS resources — S3 buckets, DynamoDB tables, etc. The Identity Pool uses IAM roles to define what each type of guest or staff member can do. Without the front desk (User Pool), the master key system (Identity Pool) doesn't know who to trust. Without the master key system, even a verified guest can't open AWS doors.
What is Amazon Cognito?
Amazon Cognito is a fully managed identity service that provides authentication, authorization, and user management for web and mobile applications. It consists of two main components: User Pools and Identity Pools. User Pools handle user directory and sign-in (authentication), while Identity Pools provide temporary AWS credentials (authorization) to access AWS services.
User Pools: The Authentication Layer
A User Pool is a user directory that enables sign-up and sign-in for your app users. It can be used with social identity providers (Google, Facebook, Amazon), enterprise providers via SAML, and OIDC providers. The User Pool issues JSON Web Tokens (JWTs) after successful authentication. There are three types of tokens: ID token (contains user attributes), Access token (used to authorize API calls), and Refresh token (used to get new tokens without re-authentication).
Key Features: - Customizable sign-up and sign-in pages via the hosted UI or your own UI with the Amplify SDK. - Multi-factor authentication (MFA) with TOTP or SMS. - Adaptive authentication to block suspicious sign-ins. - User attributes like email, phone, and custom attributes. - Lambda triggers for custom workflows (pre sign-up, post authentication, etc.). - Token expiration defaults: Access token 1 hour, ID token 1 hour, Refresh token 30 days (configurable).
How it works: 1. User submits credentials (username/password) to the User Pool endpoint. 2. User Pool validates credentials against its directory. 3. On success, User Pool returns a JWT token set. 4. The app uses these tokens to authenticate to your backend APIs (e.g., API Gateway with Cognito authorizer).
Server-side verification: Your backend can verify the token by calling the GetId and GetCredentialsForIdentity APIs or by validating the JWT signature using the User Pool's public keys (available at a well-known JWKS URI).
Identity Pools: The Authorization Layer
An Identity Pool (formerly known as a Federated Identity) provides temporary AWS credentials for authenticated and unauthenticated users. It acts as a broker between your identity source (User Pool, social providers, SAML, or even anonymous users) and AWS STS (Security Token Service).
Key Features:
- Supports multiple identity providers: User Pools, SAML, OIDC, social logins, and developer authenticated identities.
- Anonymous access: For guest users, you can grant limited access to AWS resources.
- IAM role-based access: You define two IAM roles — one for authenticated users, one for unauthenticated (guest) users.
- Fine-grained permissions: Use IAM policies with conditions like cognito-identity.amazonaws.com:sub to restrict access to specific user IDs.
- Cognito Streams: Send records of identity operations to Kinesis Firehose for analytics.
How it works:
1. User authenticates with an identity provider (e.g., User Pool) and gets a token.
2. The app calls GetId with the provider token to get a Cognito identity ID.
3. Then calls GetCredentialsForIdentity with the identity ID and token to get temporary AWS credentials (Access Key, Secret Key, Session Token).
4. The app uses these credentials to access AWS services (S3, DynamoDB, etc.).
Important: The temporary credentials expire after a configurable duration (default 1 hour, min 15 minutes, max 24 hours). The Identity Pool automatically refreshes credentials for authenticated users.
User Pool vs Identity Pool: The Exam's Core Distinction
The SAA-C03 exam frequently asks: "Which Cognito component should you use for X?" The rule of thumb:
Use User Pools when you need to authenticate users (verify identity).
Use Identity Pools when you need to authorize access to AWS resources (grant permissions).
Often, you use both: User Pool for sign-in, then Identity Pool to exchange the User Pool token for AWS credentials.
How They Interact
A common architecture:
1. User signs in via User Pool, receives JWT.
2. App passes the JWT to Identity Pool via GetCredentialsForIdentity.
3. Identity Pool validates the JWT with the User Pool.
4. Identity Pool assumes an IAM role and returns temporary credentials.
5. App uses those credentials to access S3, DynamoDB, etc.
Alternatively, you can use the User Pool token directly with API Gateway (using a Cognito authorizer) without involving Identity Pool.
Configuration Steps (Console)
Create a User Pool: 1. Go to Cognito Console > User Pools > Create user pool. 2. Configure sign-in options (username, email, phone). 3. Configure security requirements (password policy, MFA). 4. Configure attributes and attribute verification. 5. Configure message delivery (SNS for SMS, SES for email). 6. Configure app client (with or without client secret). 7. Review and create.
Create an Identity Pool: 1. Go to Cognito Console > Identity Pools > Create new identity pool. 2. Enable access to unauthenticated identities (optional). 3. Choose authentication providers (User Pool, Google, etc.). 4. Configure IAM roles for authenticated and unauthenticated users. 5. Create pool.
Defaults and Limits
User Pool: Default password policy: minimum 8 characters, require uppercase, lowercase, numbers, special characters. Max user pool size: 10 million users per pool. Max number of user pools per account: 60.
Identity Pool: Max number of identity pools per account: 60. Max number of identity IDs per pool: unlimited. Temporary credential duration: 15 minutes to 24 hours (default 1 hour).
Token sizes: JWTs are typically a few KB. Keep custom attributes small to avoid token bloat.
Lambda Triggers (User Pool)
You can attach Lambda functions to user pool events: - Pre sign-up: Validate or auto-verify user attributes before sign-up completes. - Post confirmation: Send a welcome email or create a user record in DynamoDB. - Pre authentication: Block sign-in based on custom logic (e.g., user banned). - Post authentication: Log sign-in events. - Custom message: Customize email/SMS messages. - Define auth challenge: Custom authentication flows. - Create auth challenge: Generate custom challenges. - Verify auth challenge response: Verify answers to custom challenges.
Security Considerations
Always use HTTPS for API calls.
Token validation: Validate JWTs on your backend by checking the signature, expiration, and issuer.
Least privilege: Grant only necessary permissions in Identity Pool IAM roles.
MFA: Enforce MFA for sensitive actions.
Client-side security: Never expose client secret in mobile apps (use public client instead).
CLI Example: Creating a User Pool
aws cognito-idp create-user-pool \
--pool-name MyUserPool \
--policies 'PasswordPolicy: {MinimumLength: 8, RequireUppercase: true, RequireLowercase: true, RequireNumbers: true, RequireSymbols: true}' \
--auto-verified-attributes emailCLI Example: Creating an Identity Pool
aws cognito-identity create-identity-pool \
--identity-pool-name MyIdentityPool \
--allow-unauthenticated-identities \
--supported-login-providers 'accounts.google.com=my-google-client-id'Common Exam Scenarios
Mobile app accessing S3: Use User Pool for sign-up/sign-in, then Identity Pool to get temporary credentials for S3.
Web app with API Gateway: Use User Pool tokens directly with API Gateway Cognito authorizer. No Identity Pool needed.
Social login only: Use Identity Pool directly with social providers (no User Pool).
Guest access: Enable unauthenticated identities in Identity Pool for limited access.
Enterprise federation: Use SAML or OIDC with User Pool or Identity Pool.
Trap: Using User Pool for Authorization
A common mistake is thinking a User Pool alone can grant access to AWS resources. It cannot. User Pools only authenticate. To authorize access to S3 or DynamoDB, you must use Identity Pool or IAM roles directly (e.g., using Cognito authorizer with API Gateway and then a Lambda function that assumes a role).
Trap: Mixing Up Token Types
ID token: Contains user attributes. Use to get user info.
Access token: Used to authorize API calls to your backend.
Refresh token: Used to get new tokens. Not used with Identity Pool directly.
Identity Pool uses the ID token (or access token from social providers) to authenticate with the identity pool.
Summary of Differences
| Feature | User Pool | Identity Pool | |---------|-----------|---------------| | Purpose | Authentication (verify identity) | Authorization (grant AWS access) | | Output | JWT tokens | Temporary AWS credentials | | User directory | Yes | No (broker only) | | Social login | Yes, via OIDC | Yes, directly | | SAML federation | Yes | Yes | | Anonymous access | No | Yes | | IAM roles | No | Yes | | Lambda triggers | Yes | No | | MFA | Yes | No (relies on provider) |
Conclusion
Amazon Cognito provides a complete identity solution. User Pools handle the "who" — authenticating users and managing their profiles. Identity Pools handle the "what" — granting temporary AWS credentials based on identity. For the SAA-C03, know when to use each, how they work together, and common misconfigurations.
User Registration
The user submits a sign-up request to the User Pool with required attributes (e.g., email, password). The User Pool validates the password policy (minimum length, complexity) and checks for duplicate usernames. If auto-verify is configured, the User Pool sends a verification code via email or SMS. The user confirms their account by entering the code. Optionally, a pre sign-up Lambda trigger can run to validate or reject the registration based on custom logic (e.g., checking a blocklist).
User Authentication
The user signs in by sending their credentials (username and password) to the User Pool's `InitiateAuth` endpoint. The User Pool authenticates against its directory. If MFA is enabled and the user has an MFA device, the User Pool returns a challenge for the TOTP code. The user responds with `RespondToAuthChallenge`. On success, the User Pool returns three tokens: ID token, Access token, and Refresh token. The tokens are JWTs containing claims like `sub` (user ID), `iss` (issuer), `exp` (expiration), and custom attributes.
Token Exchange with Identity Pool
The app calls `GetId` with the provider name (e.g., `cognito-idp.us-east-1.amazonaws.com/us-east-1_xxxxxxxxx`) and the ID token from the User Pool. The Identity Pool validates the token's signature and issuer using the User Pool's public keys. It returns a unique Cognito identity ID (e.g., `us-east-1:12345678-xxxx-xxxx-xxxx-xxxxxxxxxxxx`). Then the app calls `GetCredentialsForIdentity` with the identity ID and the same ID token. The Identity Pool assumes the IAM role configured for authenticated users and returns temporary AWS credentials (Access Key, Secret Key, Session Token).
AWS Resource Access
The app uses the temporary credentials to sign AWS API calls. For example, it can put an object in S3 using the AWS SDK. The IAM policy attached to the role determines which actions are allowed. The policy can include conditions like `aws:SourceIp` or `cognito-identity.amazonaws.com:sub` to restrict access to specific users. The credentials are valid for the configured duration (default 1 hour). The SDK automatically refreshes credentials when they expire by calling `GetCredentialsForIdentity` again with the refresh token (for User Pool) or by using the session token's expiration.
Token Refresh
When the Access token expires (after 1 hour), the app can use the Refresh token to get new tokens without requiring the user to re-enter credentials. The app calls `InitiateAuth` with `REFRESH_TOKEN_AUTH` flow, passing the Refresh token. The User Pool returns new ID, Access, and Refresh tokens. The new Refresh token has a renewed expiration (default 30 days from original issue). If the Refresh token expires, the user must sign in again. For Identity Pool, credentials are refreshed automatically by the SDK using the same identity ID and provider token.
Enterprise Scenario 1: Mobile App for a Retail Company
A retail company builds a mobile app for customers to view order history and manage loyalty points. They use a User Pool for customer sign-up and sign-in, with social login via Google and Facebook. After authentication, the app uses an Identity Pool to get temporary credentials to access a DynamoDB table containing loyalty points. The IAM role for authenticated users allows only GetItem and UpdateItem on the specific table, with a condition that the user can only access their own records using cognito-identity.amazonaws.com:sub. The company also enables unauthenticated access for browsing products (read-only access to a product catalog in DynamoDB). Performance considerations: The User Pool handles thousands of sign-ins per minute with minimal latency. The Identity Pool caches credentials locally on the device for the duration of the session (1 hour). Misconfiguration: If the IAM role is too permissive (e.g., DynamoDB:*), a malicious user could delete other users' data. To prevent this, use fine-grained IAM policies with condition keys.
Enterprise Scenario 2: Enterprise SaaS Application with SAML Federation
A SaaS provider offers a web application for enterprise customers. Each customer uses their own SAML 2.0 identity provider (e.g., Okta, ADFS). The application uses a User Pool as the user directory for each tenant (or a single User Pool with custom attributes for tenant isolation). The User Pool is configured with a SAML identity provider for each enterprise. When an employee signs in, they are redirected to their company's IdP, which returns a SAML assertion. The User Pool validates the assertion and issues JWTs. The application then uses the Identity Pool to get temporary credentials for accessing S3 buckets per tenant. The IAM role for authenticated users has a policy that restricts access to the tenant's S3 prefix using s3:prefix condition. Scale: A single User Pool can support up to 10 million users, but for multi-tenant isolation, separate User Pools per tenant are recommended. Common problem: If the SAML IdP is misconfigured (e.g., wrong ACS URL), authentication fails. Also, if the IdP's metadata changes, the User Pool must be updated.
Enterprise Scenario 3: Guest Access for a Public Event App
A conference app allows attendees to view the schedule and speaker bios without signing in. The app uses an Identity Pool with unauthenticated access enabled. The IAM role for unauthenticated users has a policy that allows read-only access to a DynamoDB table containing event data. For attendees who want to submit feedback or save sessions, they sign up via a User Pool. After sign-in, the Identity Pool provides elevated credentials that allow write access to a feedback DynamoDB table. The app uses the cognito-identity.amazonaws.com:aud condition in IAM to differentiate between authenticated and unauthenticated users. Performance: The Identity Pool can handle high concurrency, but unauthenticated requests are subject to throttling limits (default 100 requests per second per identity pool). Misconfiguration: If the unauthenticated role grants write access, anonymous users could vandalize data. Always grant least privilege.
The SAA-C03 exam tests Cognito under Domain 1: Secure Architectures (Objective 1.1) and Domain 2: Resilient Architectures. Expect 2-3 questions on Cognito, often asking you to choose between User Pools and Identity Pools for a given scenario.
Common Wrong Answers: 1. "Use an Identity Pool for authentication." — Wrong. Identity Pools do not authenticate users; they only provide credentials. Authentication is done by User Pools or external providers. 2. "User Pools can directly grant access to S3." — Wrong. User Pools issue JWTs, not AWS credentials. To access S3, you need Identity Pool or IAM roles. 3. "You cannot use social logins with User Pools." — Wrong. User Pools support social identity providers via OIDC. 4. "Cognito User Pools are IAM users." — Wrong. Cognito users are separate from IAM users. Cognito is for app users, IAM is for AWS users (admins, services).
Specific Numbers and Terms:
- Token expiration defaults: Access/ID token = 1 hour, Refresh token = 30 days.
- Min password length: 8 characters (configurable).
- Max user pool size: 10 million users.
- Identity Pool credential duration: 15 min to 24 hours (default 1 hour).
- Terms: JWT, sub, iss, GetId, GetCredentialsForIdentity, InitiateAuth, RespondToAuthChallenge.
Edge Cases:
- Anonymous access: Identity Pool allows unauthenticated identities. The exam may test that this is the only way to grant AWS access to guest users.
- Custom authentication: User Pool supports custom challenge flows via Lambda triggers. The exam may ask which Lambda trigger to use for custom authentication (e.g., DefineAuthChallenge, CreateAuthChallenge, VerifyAuthChallengeResponse).
- Token validation: You must validate JWTs on your backend. The exam may ask where to get the public keys (JWKS URI from User Pool).
Eliminating Wrong Answers: - If the question mentions "authenticate" or "sign-in", the answer is almost always User Pool. - If the question mentions "temporary AWS credentials" or "access S3", the answer is Identity Pool. - If the question mentions "federated identity with Google", both can work, but Identity Pool is simpler if no user directory is needed. - If the question mentions "MFA", it's User Pool (Identity Pool does not have its own MFA). - If the question mentions "Lambda triggers for sign-up", it's User Pool.
Exam Tip: Read carefully: Does the scenario require a user directory? If yes, use User Pool. Does it require AWS resource access? If yes, use Identity Pool (or both).
User Pools authenticate users; Identity Pools authorize access to AWS resources.
User Pools issue JWTs (ID, Access, Refresh tokens) with default expiration of 1 hour for Access/ID, 30 days for Refresh.
Identity Pools require a token from a trusted provider (User Pool, social, SAML) or allow anonymous access.
To give app users access to S3, combine a User Pool (authentication) with an Identity Pool (authorization).
Identity Pool temporary credentials default to 1 hour, configurable from 15 minutes to 24 hours.
User Pool Lambda triggers (e.g., PreSignUp, PostConfirmation) allow custom workflows during authentication lifecycle.
Cognito is not for IAM users; it's for application end-users (customers, employees via federation).
The SAA-C03 exam tests the distinction between authentication and authorization in Cognito.
These come up on the exam all the time. Here's how to tell them apart.
Cognito User Pool
Provides authentication: user sign-up, sign-in, password recovery
Issues JWT tokens (ID, Access, Refresh)
Has a built-in user directory (up to 10 million users)
Supports MFA, adaptive authentication, Lambda triggers
Cannot directly grant AWS resource access
Cognito Identity Pool
Provides authorization: temporary AWS credentials
Issues AWS access keys, secret keys, session tokens
Does not have a user directory; brokers between identity providers and AWS STS
Supports anonymous (unauthenticated) access
Required to access AWS services like S3, DynamoDB, etc.
Mistake
Cognito User Pools can directly grant access to S3 buckets.
Correct
User Pools only authenticate users and issue JWTs. They do not provide AWS credentials. To access S3, you must use an Identity Pool to exchange the User Pool token for temporary AWS credentials, or use API Gateway with a Cognito authorizer and a Lambda function that assumes an IAM role.
Mistake
Identity Pools can authenticate users without any external provider.
Correct
Identity Pools are not authentication providers. They require an identity token from a trusted provider (User Pool, social login, SAML, OIDC) or allow unauthenticated (anonymous) access. They do not have a user directory or password verification.
Mistake
Cognito User Pools are the same as IAM users.
Correct
IAM users are for AWS administrators and services, with long-term credentials. Cognito User Pool users are for app end-users, with temporary tokens. They are separate systems. IAM users cannot sign in to a Cognito User Pool app.
Mistake
You cannot use social identity providers with Cognito User Pools.
Correct
User Pools support social identity providers (Google, Facebook, Amazon, Apple) via OIDC. You configure the provider's client ID and secret in the User Pool. Users can sign in with their social accounts, and the User Pool issues JWTs after successful federation.
Mistake
Cognito tokens never expire.
Correct
Access and ID tokens expire after a configurable duration (default 1 hour). Refresh tokens expire after 30 days by default. Short-lived tokens improve security; you must implement token refresh logic in your app.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A User Pool handles authentication (sign-up, sign-in, user directory) and issues JWTs. An Identity Pool handles authorization by exchanging tokens from a User Pool or other identity provider for temporary AWS credentials to access AWS services. In short: User Pool = who you are, Identity Pool = what you can do.
Yes. You can use an Identity Pool alone with social identity providers (Google, Facebook) or SAML/OIDC providers. The Identity Pool will authenticate users via those providers and issue AWS credentials. However, you lose the user directory features (MFA, custom attributes, Lambda triggers). For many apps, combining both is best.
Use a User Pool for authentication, then an Identity Pool to exchange the User Pool token for temporary AWS credentials. Configure the Identity Pool's IAM role for authenticated users with a policy that allows the desired S3 actions (e.g., s3:PutObject). The app uses those credentials to make S3 API calls.
Lambda triggers are functions that run during User Pool events like sign-up, sign-in, and token creation. Use them for custom validation (e.g., rejecting sign-ups from certain email domains), post-authentication logging, or custom authentication challenges. For example, a PreSignUp trigger can auto-verify users from a corporate domain.
Download the User Pool's public keys from the JWKS URI (https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json). Verify the JWT signature, expiration, issuer (iss), and audience (aud). Do not trust tokens without validation. AWS SDKs provide libraries for this (e.g., aws-jwt-verify for Node.js).
Cognito is designed for end-user authentication. For server-to-server, use IAM roles, STS, or API Gateway with IAM authorization. Cognito User Pools require a user interface for sign-in, though you can use the client credentials OAuth flow for machine-to-machine (but it's not typical).
Up to 10 million users per User Pool. If you need more, you can create multiple User Pools. There is no limit on the number of identity IDs in an Identity Pool.
You've just covered Amazon Cognito User Pools and Identity Pools — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?