Cognito: user pools and identity pools
Lesson 2 of 4 in Authentication Strategies.
Amazon Cognito is two services sharing a console, and the exam will test whether you know which one a scenario needs. Get this sentence into muscle memory:
A user pool authenticates people and returns tokens. An identity pool takes a trusted token and returns AWS credentials.
User pool = authentication, for your application. Identity pool = authorization against AWS APIs, by way of an IAM role. They are frequently used together — the user pool signs the person in, the identity pool converts that proof into credentials scoped by a role — but either works alone. A user pool with no identity pool is the right design for an app whose backend is your own API behind API Gateway. An identity pool with no user pool is the right design when the token already comes from Google, Apple, or a corporate OIDC provider.
| User pool | Identity pool | |
|---|---|---|
Job | Authentication — prove who the user is | Credential exchange — turn a trusted token into AWS access |
Returns | An ID token (OIDC, describes the user), an access token (OAuth 2.0 scopes, for your API), and a refresh token | Temporary AWS credentials — access key, secret, session token — from an IAM role |
Features you configure | Sign-up and sign-in pages, password policy, MFA (TOTP, SMS, email), threat protection (compromised credentials, adaptive authentication), federation to social and enterprise IdPs, Lambda triggers, groups, custom attributes | Authenticated and unauthenticated (guest) roles, role mapping by token claim or rule, attributes for access control |
Who consumes the output | Your application and your APIs — e.g. an API Gateway Cognito authorizer validating the token | The AWS SDK in the client, calling S3, DynamoDB, or Kinesis directly under the role |
Stem language that implies it | "users must be able to sign up and sign in", "enforce MFA on app users", "validate the JWT at the API" | "the mobile app must upload directly to S3", "guest users need read-only access", "scope access to each user’s own prefix" |
Three details inside the user pool show up in security questions.
The three tokens are not interchangeable. The ID token is an OIDC token describing who the user is — claims, groups, custom attributes — and is what an API Gateway Cognito authorizer or an identity pool consumes. The access token carries OAuth 2.0 scopes and answers what the client is permitted to request from your resource server. The refresh token buys new ones without re-authenticating, lives far longer, and is therefore the one worth protecting hardest: revoking it is how you end a session you have decided to distrust.
Lambda triggers are the extension point, and an attack surface. Pre-sign-up (enforce an email domain, reject a disposable address), pre-authentication and post-authentication (deny a suspended account, write an audit record), pre-token-generation (add or rewrite claims — including the group claims that drive role mapping), custom authentication challenges, and user migration. A trigger that adds claims is effectively part of your authorization logic; review it as such.
Threat protection is the feature family formerly described as advanced security features: compromised-credential detection against known-breached passwords, and adaptive authentication that raises risk scores on unusual sign-ins and can require MFA or block. Availability depends on the feature tier you select for the user pool, so confirm the tier before promising the capability.
Interactive sorting exercise: Each requirement needs a user pool, an identity pool, or IAM Identity Center. Sort them.
Key terms: Cognito user pool, Cognito identity pool (federated identities), Cognito role mapping, OIDC / web identity federation
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.