AWS Cloud Practitioner Study Notes · Part 56
Amazon Cognito: User Pools, Identity Pools, and JWT Authentication
AWS Cloud Practitioner study notes explaining Amazon Cognito User Pools, Identity Pools, JWTs, federation, guest access, IAM roles, and API authorisation.
An application with customer accounts needs more than a login form. It needs sign-up, password resets, email verification, MFA, token handling, social sign-in, and a safe way to authorise requests. Amazon Cognito provides managed identity features for web and mobile application users.
This is Part 56 of the AWS Cloud Practitioner Study Notes. The key distinction is:
User Pool
→ Who is this application user?
→ User directory and authentication tokens
Identity Pool
→ What temporary AWS access should this user receive?
→ Federated identities and IAM credentialsThe two components can be used independently or together. A User Pool is often enough when a backend API only needs to validate a user’s token. Add an Identity Pool when the application needs to give authenticated or guest users temporary credentials for AWS services.
What Amazon Cognito is for
Cognito is primarily a customer identity and access service. Its users are the users of your application: customers, patients, shoppers, subscribers, or members. They are different from employees who need access to the AWS console; that workforce use case normally involves IAM Identity Center.
Without a managed identity service, an application team would need to build and secure:
- User registration and sign-in
- Password hashing and reset flows
- Email or phone verification
- MFA and account recovery
- OAuth or OpenID Connect federation
- Token issuance and renewal
- Account lockout and user lifecycle handling
Cognito provides these building blocks while your application remains responsible for its own business authorisation, user experience, and secure integration.
User Pools: authentication and tokens
An Amazon Cognito User Pool is a user directory and OpenID Connect identity provider for your application. It can contain local users created through Cognito and users who sign in through configured external identity providers.
Application user
↓ signs up or signs in
Cognito User Pool
↓
ID token, access token, refresh token
↓
Application or APIUser Pools can handle features such as sign-up, sign-in, password management, verification, MFA, user attributes, groups, managed login, and federation with social, SAML, or OpenID Connect providers.
The result of a successful sign-in is a set of tokens, not AWS access keys. Your application can send an appropriate token to a backend or API Gateway, where an authoriser verifies the token and its claims.
Cognito tokens
Cognito User Pools commonly issue three token types:
| Token | Main purpose |
|---|---|
| ID token | Claims about the authenticated user, such as identity attributes |
| Access token | Authorises access to APIs, scopes, and Cognito user operations |
| Refresh token | Obtains new ID and access tokens after the short-lived tokens expire |
Tokens are JSON Web Tokens (JWTs) containing claims. An ID token is about the user’s identity. An access token is intended for authorising access to APIs and scopes. Do not treat the two tokens as interchangeable without checking the integration’s requirements.
Example application flow:
User signs in
↓
User Pool validates the sign-in
↓
Application receives JWTs
↓
Client sends an appropriate token to the API
↓
API validates issuer, signature, expiry, and claimsJWT possession alone should not be treated as permission to perform every business operation. Your API must still enforce application-level rules such as whether a user may view a particular booking or update a particular record.
Identity Pools: temporary AWS credentials
An Amazon Cognito Identity Pool is a federation service. It exchanges proof of authentication for temporary AWS credentials associated with an IAM role. It can also provide limited credentials to unauthenticated guest users when guest access is deliberately enabled.
User Pool token or another trusted IdP proof
↓
Cognito Identity Pool
↓
IAM role selection
↓
AWS STS temporary credentials
↓
S3, DynamoDB, or another AWS APIIdentity Pools do not replace a User Pool directory. They provide identities and credentials that let an application access AWS resources without embedding a long-term IAM access key in a mobile or browser application.
The IAM role attached to the identity pool determines what the temporary credentials can do. Keep that role narrowly scoped. For example, a photo application might allow authenticated users to write objects only under their own controlled S3 key prefix.
User Pool and Identity Pool together
Consider a mobile booking application that lets a signed-in customer upload a profile image:
Customer signs in
↓
User Pool returns tokens
↓
Identity Pool exchanges the token
↓
Temporary credentials for an IAM role
↓
Mobile app uploads to S3The User Pool answers “who is the customer?” The Identity Pool answers “which AWS permissions should this session receive?” AWS STS participates in issuing the temporary credentials.
An Identity Pool does not have to use a User Pool. It can trust supported social providers, SAML or OIDC providers, developer-authenticated identities, and other configured identity providers. Similarly, a User Pool can issue JWTs directly to an app or API without any Identity Pool.
Authenticated and guest users
Identity Pools support two broad identity states:
- Authenticated identities provide proof from a configured identity provider and can receive an authenticated IAM role.
- Unauthenticated identities are guest users and can receive a separate, limited IAM role if guest access is enabled.
Example:
Guest visitor
↓
Unauthenticated identity
↓
Read-only public catalogue role
Signed-in customer
↓
Authenticated identity
↓
Customer role with limited upload accessGuest credentials are still credentials. Do not grant them broad read or write access merely because the user has not signed in. Public resources should be intentionally scoped, and sensitive operations should require authentication and application-level checks.
Federation and social sign-in
User Pools can provide a consistent application-facing sign-in experience while federating with external providers. Common options include Google, Apple, Facebook, Amazon, SAML 2.0, and OpenID Connect providers, depending on the configured integration.
User chooses “Sign in with Google”
↓
Google authenticates the user
↓
Cognito User Pool maps the federated identity
↓
Cognito issues tokens for the applicationThe application can then validate one Cognito token format instead of implementing separate token handling for every upstream identity provider.
Cognito with API Gateway
A common backend pattern is to use a Cognito User Pool as an API Gateway authoriser:
Client signs in to User Pool
↓ receives token
Client sends Authorization header
↓
API Gateway Cognito authoriser
↓ valid token
Lambda or backend integrationAPI Gateway can validate a User Pool token before invoking the integration. Depending on the API configuration, the identity token or access token can be used, and access-token scopes can protect API resources.
This pattern uses User Pool tokens for API authorisation. It does not require an Identity Pool unless the client also needs temporary IAM credentials to call AWS services directly.
Cognito versus IAM and IAM Identity Center
These services solve different identity problems:
| Service | Primary users | Main purpose |
|---|---|---|
| IAM | AWS identities and workload roles | Permissions for AWS resources in an account |
| IAM Identity Center | Employees and workforce users | SSO and permission sets across AWS accounts and applications |
| Amazon Cognito User Pool | Application users | Sign-up, sign-in, federation, and JWTs |
| Amazon Cognito Identity Pool | Application users and guests | Temporary AWS credentials through IAM roles |
Use IAM roles for EC2, Lambda, and other AWS workloads. Use IAM Identity Center for employees accessing AWS accounts. Use Cognito for customers or users signing in to your application.
See AWS IAM policies for the policies attached to the roles that Identity Pools use, and AWS Organizations for the multi-account governance service that is separate from customer authentication.
Security and design considerations
Cognito removes a large amount of identity plumbing, but it does not make an application secure automatically. Design and verify the surrounding system:
- Validate JWT signature, issuer, audience or client, token use, expiry, and relevant scopes.
- Keep User Pool app-client configuration and callback URLs restricted to the intended application.
- Use least-privilege IAM roles for Identity Pool credentials.
- Treat guest access as an intentionally public capability with tightly scoped permissions.
- Keep business authorisation in the backend rather than relying only on token validity.
- Do not embed long-term IAM access keys in browser or mobile application code.
- Protect refresh tokens and use secure storage appropriate to the platform.
- Use an API or backend boundary when direct client access to AWS services is unnecessary.
Direct S3 or DynamoDB access from a client can be useful, but it adds policy, key-prefix, data-validation, and abuse-prevention complexity. A backend-mediated design may be easier to control for sensitive operations.
Common exam questions
You need a managed login system for application customers.
Use a Cognito User Pool.
You need JWTs for a backend API.
Use a Cognito User Pool and configure the API to validate its tokens, such as with an API Gateway Cognito authoriser.
You need temporary AWS credentials for a mobile application.
Use a Cognito Identity Pool with IAM roles.
A user must upload directly from a mobile app to S3 without embedded AWS keys.
Use an Identity Pool to provide limited temporary credentials, often after authenticating through a User Pool.
You need limited access for users who have not signed in.
Enable unauthenticated guest identities in an Identity Pool and assign a tightly scoped guest IAM role.
You need SSO for employees to access AWS accounts.
Use IAM Identity Center, not Cognito as the primary workforce access service.
Final memory map
Amazon Cognito
├── User Pool
│ ├── User directory
│ ├── Sign-up and sign-in
│ ├── Federation and MFA
│ └── JWT tokens
└── Identity Pool
├── Authenticated or guest identities
├── IAM role selection
└── Temporary AWS credentials through STSThe one-sentence takeaway is: Cognito User Pools authenticate application users and issue tokens, while Identity Pools federate those identities into limited temporary AWS credentials for direct access to AWS resources.