2.4 Amazon Cognito

The Single Biggest Cognito Confusion

DVA-C02 loves to test whether you know the difference between the two halves of Amazon Cognito. Memorize one sentence: user pools log users IN; identity pools hand out AWS CREDENTIALS. Nearly every Cognito question reduces to deciding which half (or both) is required.

User Pools — Authentication

A user pool is a managed user directory. It handles:

• Sign-up and sign-in, password policies, account recovery, and email/phone verification
• Multi-factor authentication (MFA) — SMS or time-based one-time password (TOTP)
• A managed Hosted UI plus OAuth 2.0 / OpenID Connect (OIDC) endpoints, and federation with social and SAML providers
• App clients and Lambda triggers (pre-sign-up, pre-token-generation, custom auth challenge) for custom flows

On success the user pool issues three JSON Web Tokens (JWTs):

API Gateway can validate a user pool JWT directly with a Cognito authorizer — no AWS credentials involved. This is the cheapest way to protect a REST API for logged-in users.

Identity Pools — Authorization to AWS

An identity pool (federated identities) does not authenticate users. It takes a token — from a Cognito user pool, Google, Facebook, Apple, SAML, or any OIDC provider — and exchanges it through AWS STS for temporary AWS credentials. Those credentials let the user call AWS services such as S3 or DynamoDB directly under an IAM role.

Identity pools support two role types:

• Authenticated role — for users who signed in with an identity provider.
• Unauthenticated (guest) role — for anonymous users you explicitly choose to allow.

Role selection can use a default role, rule-based mapping on token claims, or attribute-based access control (ABAC) that injects token attributes as IAM Condition values, so one role can scope each user to their own S3 prefix or DynamoDB items.

How They Work Together

User → User Pool (login) → JWT → Identity Pool → STS → AWS credentials → S3/DynamoDB

• Need only sign-in / a logged-in identity (e.g., protect an API behind a Cognito authorizer) → user pool alone.
• Need users to call AWS services directly from the client → user pool plus identity pool.
• Need guest access to AWS resources with no login → identity pool with an unauthenticated role.

Common Exam Traps

• Treating the ID token as an API authorization token — that is the access token's job.
• Thinking a user pool can return AWS credentials — it cannot; only an identity pool (via STS) does.
• Provisioning a long-lived IAM user per app user — never the answer; identity pools vend short-lived credentials instead.

Federation and Hosted UI

A user pool can federate external identity providers so users sign in with existing accounts. Social providers (Google, Facebook, Apple, Amazon) use OAuth/OIDC; enterprise providers connect via SAML 2.0 or generic OIDC. The Hosted UI is an AWS-managed, brandable sign-in page reachable at your user pool domain; it implements the OAuth 2.0 authorization-code and implicit flows so you do not build login screens yourself. App clients can also use direct SDK flows like USER_SRP_AUTH (Secure Remote Password, which never sends the password over the wire) for custom front ends.

Securing APIs: Authorizer Choices

For protecting an API behind logged-in users, the exam compares three options:

If the scenario says users authenticate with a Cognito user pool and you must protect an API Gateway endpoint, the Cognito authorizer is almost always the lowest-effort correct answer.

Token Validation and Lifetimes

Clients should validate the JWT signature against the user pool's public JSON Web Key Set (JWKS) and check exp, aud/client_id, and iss. Access and ID tokens default to a one-hour lifetime; the refresh token (default 30 days, configurable from 5 minutes to 10 years) is exchanged at the token endpoint for fresh access and ID tokens, so users are not forced to log in hourly. Never use the refresh token to call APIs directly — only the access token authorizes resource calls.

Lambda Triggers and Customization

User pools expose Lambda triggers at key lifecycle points, and the exam expects you to map a customization to the right trigger. The pre-sign-up trigger can auto-confirm or auto-verify users; the pre-authentication and post-authentication triggers run around login for logging or risk checks; the pre-token-generation trigger adds or suppresses custom claims in the ID/access token (for example, injecting a tenant ID or a group-derived role); and the custom auth challenge triggers (define/create/verify) implement passwordless or CAPTCHA flows.

A worked scenario: to embed a customer's subscription tier into the token so downstream APIs can authorize on it without a database lookup, use the pre-token-generation trigger to add a custom claim. Combined with a Cognito authorizer, this lets API Gateway authorize requests entirely from the validated JWT — no extra round trips, lower latency, and a clean separation between authentication (user pool) and AWS authorization (identity pool).