SysPad › Lessons › security lessons › Cognito
How Cognito works
Managed user identity: sign-up, sign-in, MFA, social federation, and JWT token issuance. Default 25 sign-in ops/sec (adjustable). Auth latency is 100-300ms; token refresh ~50ms.
Building auth yourself, sign-up, login, password resets, MFA, social login, securely, is a trap most teams regret. Cognito does it for you. The one thing that confuses everyone is that it’s really two services: User Pools (who is this user?) and Identity Pools (what AWS access do they get?). Knowing which is which clears up most of the confusion.
What you will learn
- Why not build authentication yourself?
- What does a User Pool do, and what are the tokens it issues?
- What different problem does an Identity Pool solve?
- When do you use one, the other, or both?
Don’t build auth from scratch
Authentication looks simple and isn’t: secure password storage, resets, email/phone verification, MFA, lockouts, social and enterprise login, and tokens. Cognito provides all of this as a managed service, so you wire it in instead of reinventing it (and getting it subtly wrong).
User Pools: who is this user?
A User Pool is a managed user directory. It handles sign-up and sign-in, MFA, password policies, and federation (let users log in with Google, Apple, or a corporate SAML/OIDC identity provider). On success it issues JWT tokens: an ID token (who the user is), an access token (what they can call), and a refresh token.
Your app or API verifies these tokens to authenticate requests, no passwords flow through your code.
⚓ Web/mobile app logins, B2B SSO, and any API that needs to know who’s calling.
Identity Pools: what AWS access do they get?
An Identity Pool (federated identities) solves a different problem: it exchanges a verified token (from a User Pool, Google, etc.) for temporary AWS IAM credentials. That lets a client app call AWS services directly, e.g. upload to a specific S3 prefix, scoped by an IAM role.
One, the other, or both
Common patterns: User Pool only (app authenticates users and calls your own API with the tokens), Identity Pool only (federate an external IdP to get AWS credentials), or both (User Pool authenticates, Identity Pool then grants scoped AWS access).
Flashcards
- Why use Cognito instead of building auth yourself?
- It provides managed, secure auth, sign-up/in, MFA, resets, federation, tokens, so you don’t reinvent (and risk) it.
- What is a Cognito User Pool, and what does it issue?
- A managed user directory (sign-up/in, MFA, federation). On sign-in it issues JWT tokens (ID, access, refresh).
- What does a Cognito Identity Pool do?
- Exchanges a verified token for temporary AWS IAM credentials, so a client can call AWS services directly, scoped by an IAM role.
- One-line difference: User Pool vs Identity Pool?
- User Pool = who is this user (authentication + tokens). Identity Pool = what AWS access they get (temporary credentials).
- App just logs users in and calls your own API. Which Cognito piece?
- A User Pool, its tokens authenticate calls to your backend. An Identity Pool is only needed for direct AWS-service access.
Sources
- AWS, What is Amazon Cognito
- AWS, Cognito User Pools (auth, tokens, federation)
- AWS, Cognito Identity Pools (temporary AWS credentials)
- AWS, Using tokens with user pools
Open the SysPad canvas · Official Cognito documentation