6.4 Amazon Cognito and Identity Federation

Cognito User Pools — Authentication

Quick Answer: User Pools = a hosted user directory that signs people in and returns JWT tokens. Identity Pools (a.k.a. federated identities) = swap a trusted token for temporary AWS credentials so a client app can call S3, DynamoDB, etc. Used together: User Pool authenticates → Identity Pool authorizes direct AWS access. The exam tests when you need one, the other, or both.

A User Pool is a fully managed directory handling registration, sign-in, password policy, MFA, and account recovery for customer-facing apps.

Pattern: User Pool + API Gateway (no AWS creds needed)

When a client only needs to call your API (not AWS services directly), the User Pool alone suffices:

1. User signs in to the User Pool and receives a JWT.
2. The client sends the JWT in the Authorization header on each request.
3. API Gateway uses a Cognito authorizer to validate the token signature, issuer, and expiry.
4. Valid requests reach the backend Lambda; invalid ones get a 401.

This pattern needs no Identity Pool, because the client never touches AWS APIs directly — a frequent distractor on the exam.

Identity Pools and Federation Choices

Cognito Identity Pools — temporary AWS credentials

An Identity Pool trades a verified token (from a User Pool, a social IdP, SAML, or OIDC) for temporary AWS credentials via AWS STS, then maps the caller to an IAM role.

Worked example — per-user S3 isolation: A photo app lets each user upload to only their own prefix. Configure the authenticated role with an S3 policy condition using ${cognito-identity.amazonaws.com:sub} so the principal can read/write only arn:aws:s3:::app-bucket/users/${cognito-identity.amazonaws.com:sub}/*. The client never holds long-lived keys; credentials expire and refresh automatically.

Choosing the right federation service

Decision flow

1. Does the client call only your own API? → User Pool + API Gateway authorizer.
2. Does the client call AWS services directly (S3, DynamoDB)? → User Pool + Identity Pool.
3. Are these employees logging into the AWS Console/CLI? → IAM Identity Center, not Cognito.

Common trap: Picking Cognito for employee console SSO. Cognito is built for customer-facing apps; workforce console SSO across multiple accounts is IAM Identity Center with SAML to Active Directory.

On the Exam: "Mobile app uploads photos directly to each user's own S3 folder" → User Pool (auth) + Identity Pool (temporary creds) + S3 policy scoped by identity. "Validate JWTs on a REST API" → User Pool + API Gateway authorizer (no Identity Pool).

Tokens, scale, and security details worth knowing

A User Pool issues three JWTs with distinct jobs: the ID token carries identity claims (email, name) for your app, the access token carries OAuth scopes used to authorize API calls, and the refresh token (valid far longer) silently obtains new ID and access tokens so users are not forced to re-authenticate. Access and ID tokens default to a one-hour lifetime, which is why refresh-token handling matters in mobile apps. User Pools scale to tens of millions of users and integrate MFA and adaptive authentication that raises the challenge when sign-in risk looks high (new device, impossible travel).

Common architecture and design pitfalls

For server-side web apps that already authenticate users another way, you may not need Cognito at all — but for greenfield customer apps, Cognito removes the burden of building secure password storage, recovery, and federation yourself. A frequent design pitfall is granting the Identity Pool's authenticated role overly broad permissions; always scope it with policy variables (such as the Cognito identity sub) so one user cannot read another's data. Another pitfall is using guest (unauthenticated) access without realizing those anonymous credentials still map to a real IAM role — lock that role down tightly or disable guest access.

Finally, remember that SAML and OIDC providers can plug into a User Pool (so corporate users sign in through your app's hosted UI), whereas console SSO for staff belongs to IAM Identity Center; mixing these two up is the single most common Cognito mistake on the exam.