Cargando...
Cargando...
Authentication vs Authorization — know exactly which Cognito service to use and when
User Pools authenticate WHO you are; Identity Pools authorize WHAT you can access in AWS
| Feature | Cognito User Pools Managed user directory and authentication | Identity Pools Temporary AWS credentials for any identity |
|---|---|---|
Core Purpose This is the #1 distinction tested. User Pools = AuthN, Identity Pools = AuthZ to AWS resources | Authentication — verifies user identity and issues tokens (JWT) | Authorization — exchanges tokens/credentials for temporary AWS IAM credentials |
Primary Output / Artifact If the question mentions 'temporary AWS credentials' or 'access S3/DynamoDB directly', the answer is Identity Pools | JWT tokens: ID Token, Access Token, Refresh Token (OpenID Connect compliant) | Temporary AWS credentials: Access Key ID, Secret Access Key, Session Token (via STS AssumeRoleWithWebIdentity) |
What It Manages Identity Pools do NOT store user data or passwords — they only broker AWS access | User directory: usernames, passwords, MFA, account recovery, user attributes, groups | Identity federation mapping: maps external identities to IAM roles — does NOT store user profiles |
Supported Identity Sources Identity Pools uniquely support UNAUTHENTICATED (guest) access — a common exam scenario for public read-only S3 or analytics | Built-in user directory, SAML 2.0 IdPs, OIDC IdPs, Social IdPs (Google, Facebook, Apple, Amazon) | Cognito User Pools, SAML, OIDC, Social IdPs (Google, Facebook, Apple, Amazon), Developer Authenticated Identities, Unauthenticated (Guest) access |
AWS Service Access Critical trap: A User Pool token alone cannot call DynamoDB. You need Identity Pools to get STS credentials first | Does NOT grant AWS service access directly — tokens must be exchanged via Identity Pools or used with API Gateway authorizers | YES — primary purpose is granting scoped AWS service access (S3, DynamoDB, Lambda, etc.) via IAM roles |
IAM Integration Identity Pools use two IAM roles minimum: one for authenticated users, one for unauthenticated (guest) users | Integrates with API Gateway as a built-in authorizer; User Pool Groups can be mapped to IAM roles (via Identity Pools) | Directly assumes IAM roles via STS; supports authenticated role, unauthenticated role, and role-based access control (RBAC) with role mapping rules |
MFA Support | YES — TOTP (software token), SMS MFA, optional or required per user/group | NO — MFA is not a concept here; it delegates auth to the upstream IdP |
User Registration & Sign-In UI | YES — Hosted UI (OAuth 2.0 compliant), customizable login page, built-in sign-up/sign-in flows | NO — no user-facing UI; purely a backend credential broker |
Lambda Triggers / Hooks Lambda triggers on User Pools are heavily tested — especially Pre Token Generation (add custom claims) and User Migration | YES — rich Lambda trigger ecosystem: Pre Sign-up, Post Confirmation, Pre Authentication, Post Authentication, Pre Token Generation, Custom Message, User Migration, Define/Create/Verify Auth Challenge | NO Lambda triggers — logic is handled via IAM role mapping rules and trust policies |
Token / Credential Lifetime Refresh tokens in User Pools can be configured up to 10 years — useful for mobile apps | ID/Access Token: 5 minutes to 24 hours (default 1 hour); Refresh Token: 60 minutes to 3650 days (default 30 days) | Temporary STS credentials: 15 minutes to 12 hours (default 1 hour); governed by IAM role session duration |
Guest / Unauthenticated Access Scenario: 'Allow anonymous users to upload analytics events to Kinesis' → Identity Pools with unauthenticated role | NOT supported — all users must authenticate | YES — unauthenticated identities get a separate IAM role with restricted permissions (e.g., read-only S3) |
OAuth 2.0 / OIDC Compliance | YES — full OAuth 2.0 authorization server with Authorization Code, Implicit, and Client Credentials flows; issues OIDC-compliant ID tokens | Consumes OIDC tokens as input; is NOT itself an OAuth 2.0 server |
API Gateway Integration Two valid patterns: (1) User Pool Authorizer on API Gateway validates JWT. (2) Identity Pool → STS creds → SigV4 signed request to API Gateway with IAM auth | Native integration as a Cognito User Pool Authorizer — API Gateway validates JWT automatically without Lambda | No direct API Gateway authorizer — credentials are used to sign requests with SigV4 (IAM authorization on API Gateway) |
Pricing Model SAML/OIDC federated users in User Pools cost more than direct sign-in users — a common architectural cost consideration | Based on Monthly Active Users (MAUs). Free tier: 10,000 MAUs/month for direct sign-in users. SAML/OIDC federation users have a separate (higher) price tier per MAU. | Free for the first 50,000 MAUs/month. Beyond that, pricing per MAU applies. Unauthenticated identities are also counted. |
Advanced Security Features | YES — Adaptive Authentication (risk-based), Compromised Credential Detection, Account Takeover Protection (requires Advanced Security add-on, additional cost) | NO — security is delegated to IAM policies and the upstream IdP |
Typical Architecture Role | Front-door: handles login page, user management, token issuance for web/mobile apps | Backend broker: sits between authenticated users and AWS services, swapping tokens for STS credentials |
Combined Usage Pattern The most common production pattern uses BOTH: User Pool for AuthN → Identity Pool for AWS resource AuthZ. This is the canonical mobile app architecture. | Acts as the Identity Provider — user logs in, receives JWT tokens | Accepts the User Pool JWT, calls STS, returns temporary AWS credentials to the client app |
Summary
Use Cognito User Pools when you need to authenticate users, manage a user directory, issue JWT tokens, or protect an API Gateway endpoint with a built-in authorizer. Use Identity Pools when you need to grant users (authenticated OR guest) temporary, scoped AWS IAM credentials to directly call AWS services like S3, DynamoDB, or Kinesis. In most real-world mobile and web applications, both services are used together: User Pools handle login and token issuance, while Identity Pools exchange those tokens for AWS credentials.
🎯 Decision Tree
Does the question involve LOGIN, SIGN-UP, MFA, JWT tokens, or API Gateway authorization? → Cognito User Pools. Does the question involve accessing AWS services directly (S3, DynamoDB), temporary IAM credentials, guest/unauthenticated access, or STS? → Identity Pools. Does the question involve a complete mobile app auth flow end-to-end? → BOTH services working together (User Pool → Identity Pool → STS → AWS service).
CRITICAL DISTINCTION — User Pools issue JWT tokens (ID, Access, Refresh). Identity Pools issue temporary AWS IAM credentials (via STS). If the exam scenario mentions calling S3, DynamoDB, Kinesis, or any AWS SDK call directly from a mobile/web app, the answer ALWAYS involves Identity Pools — User Pool tokens alone cannot authorize AWS API calls.
COMBINED PATTERN IS THE MOST TESTED ARCHITECTURE: User Pool authenticates the user → app receives JWT → app sends JWT to Identity Pool → Identity Pool calls STS AssumeRoleWithWebIdentity → app receives temporary AWS credentials → app calls AWS services directly. Know every step of this flow cold.
UNAUTHENTICATED (GUEST) ACCESS requires Identity Pools — User Pools cannot do this. Classic exam scenario: 'Allow anonymous mobile app users to submit analytics to Kinesis Firehose' or 'provide read-only S3 access before login.' The answer is Identity Pools with an unauthenticated IAM role configured.
API GATEWAY AUTHORIZER TRAP: Cognito User Pool Authorizer on API Gateway validates JWT tokens natively (no Lambda needed). If the question says 'use IAM authorization on API Gateway,' that means SigV4-signed requests using Identity Pool credentials — NOT User Pool tokens. These are two completely different authorization mechanisms on API Gateway.
LAMBDA TRIGGERS are ONLY on User Pools, not Identity Pools. The Pre Token Generation trigger lets you add custom claims to JWTs before they're issued — a powerful pattern for embedding application-specific roles or permissions into the token. The User Migration trigger enables zero-downtime migration from a legacy auth system.
PRICING GOTCHA: SAML/OIDC federated users in a User Pool are billed at a higher MAU rate than direct sign-in users. If a cost-optimization question asks about reducing Cognito costs for enterprise SSO users, consider whether Identity Pools (federating directly without going through a User Pool) is more cost-effective for that use case.
The #1 exam trap: Candidates see 'Cognito' and assume User Pools handles everything, including AWS resource access. It does NOT. A User Pool JWT token cannot directly call DynamoDB, S3, or any AWS service. You MUST exchange that token through an Identity Pool to get STS temporary credentials. Questions that describe a mobile app needing to 'directly access AWS services' and offer 'Cognito User Pools' as an answer choice are designed to catch this exact misconception. Always ask: does the user need to AUTHENTICATE (User Pools) or ACCESS AWS SERVICES (Identity Pools)?
CertAI Tutor · DVA-C02 · 2026-02-22
Services
Comparisons
Guides & Patterns