Cognito & Authentication

The plain-language idea

Cognito is two separate services that are commonly used together and commonly conflated:

• User Pools — a managed user directory. Sign-up, sign-in, password reset, MFA, and a hosted login UI, all handled by Cognito instead of hand-built. On successful login, a User Pool issues tokens (an ID token and access token, both JWTs) — the same kind of token this platform's JWTs-vs-sessions lesson already explains mechanically. Cognito's contribution isn't the token format; it's not having to build the directory and flows that issue it, including social login (Google, Facebook) and enterprise federation (SAML) through a hosted UI you don't build yourself.
• Identity Pools — a bridge from "this user is authenticated" to "this user can call AWS services directly." An Identity Pool takes a proven identity (a Cognito User Pool token, or a token from Google/another external provider) and exchanges it for temporary AWS credentials, scoped by an IAM role.

That second step is the same temporary-credential model this track's IAM lesson describes for a Lambda execution role — a role's policy defines exactly what the credentials can do — just handed to a browser-side user instead of a compute resource.

See it in a real thing: a browser uploading directly to S3

A photo app wants users to upload files straight from the browser to S3, without routing every upload through a backend server:

1. User signs in through a Cognito User Pool → gets back an ID token (a JWT).
2. The app hands that ID token to a Cognito Identity Pool.
3. The Identity Pool verifies the token and calls AWS STS to mint temporary credentials, tied to an IAM role configured for authenticated users.
4. The browser uses those temporary credentials to call s3:PutObject directly — no backend in the request path at all.

What people usually miss

Watch out

• User Pools and Identity Pools are separate services, not two names for the same thing. A User Pool alone proves who someone is and issues tokens — it grants zero AWS access by itself. Getting AWS credentials requires the second step, an Identity Pool.
• Social and SAML login through Cognito is federation, not Cognito doing the authenticating. Google or a corporate SAML IdP is the one actually verifying the password; Cognito's hosted UI just brokers that proof into a token your app trusts, the same "trust an external identity provider's proof" pattern as any federation setup.
• The tokens Cognito issues are ordinary JWTs and still need verifying like any JWT. Cognito being a managed service doesn't remove the fact that a JWT's payload is readable, not encrypted, and that signature verification is what a backend actually relies on — nothing about that changes because Cognito issued it.
• Temporary credentials from an Identity Pool expire like any STS-issued credentials. An app relying on direct browser-to-AWS calls has to handle re-authenticating and re-exchanging for fresh credentials when they expire mid-session, not assume one exchange lasts the whole visit.

Why this matters in interviews

"Why would you reach for Cognito instead of rolling your own auth?" tests whether a candidate can separate what Cognito actually adds — a managed user directory, hosted UI, and federation — from token mechanics they should already know generically, rather than treating Cognito as a mysterious auth black box.