The "Cognito" Confusion
Think of a hotel. When you check in at the front desk, the receptionist verifies your identity — your name, your booking, your ID. That's authentication: proving who you are. Once verified, they hand you a keycard that unlocks your specific room, the gym, and the pool — but not the staff areas. That's authorization: controlling what you can access.
Amazon Cognito is actually two completely separate services that share a brand name. Mixing them up is the single most common error in AWS security architecture, and it shows up in interviews constantly.
1. Cognito User Pools (CUP) — The Directory
A User Pool is a fully managed user directory. It answers one question: "Is this username and password correct?" It handles sign-up, sign-in, password reset, MFA, and account verification. Think of it as a hosted version of Active Directory or LDAP, purpose-built for web and mobile apps.
When a user successfully authenticates, the User Pool issues a JWT (JSON Web Token) — a cryptographically signed, self-contained token that proves the user's identity. This JWT can be validated by any service that knows the User Pool's public key, without calling Cognito again.
2. Cognito Identity Pools (Federated Identities) — The Broker
An Identity Pool answers a different question: "This user has a valid JWT — what AWS resources are they allowed to touch?" It acts as a broker: you hand it a JWT (from a User Pool, Google, Facebook, or any OIDC provider), and it hands back temporary AWS IAM credentials (an Access Key, Secret Key, and Session Token). Your app uses those credentials to call AWS APIs directly — uploading to S3, querying DynamoDB, publishing to SNS.
Rule of Thumb:
- You need a login form for your app → User Pool
- Your mobile app needs to upload files directly to S3 → Identity Pool
- You need both → User Pool feeds JWT into Identity Pool