Skip to main content
In this lesson we cover Amazon Cognito — AWS’s managed authentication and federated identity service for applications. Implementing secure authentication is difficult and error-prone; Cognito provides a production-ready solution that handles sign-up, sign-in, credential storage, session management, and federation with social and enterprise identity providers. Cognito focuses on application-level authentication (unlike IAM or IAM Identity Center, which authenticate users for AWS). It manages user directories, issues JSON Web Tokens (JWTs) for application use, and can exchange identity tokens for temporary AWS credentials so clients can access AWS resources directly. Key benefits:
  • Secure password storage and compliance with common security standards.
  • Social and enterprise identity federation (Google, Apple, Facebook, SAML/OIDC).
  • Hosted sign-in UI and SDKs for rapid integration.
  • Pay-as-you-go pricing with no minimums.
  • Designed to scale to millions of users and hundreds of TPS.
A web sign-in page for "Cognito" with an email input box and a green Continue button, plus alternative sign-in buttons for Google, Microsoft, and Apple. A "Sign up" link and a KodeKloud copyright notice appear at the bottom.
Cognito is made up of two primary components that are frequently used together but have different responsibilities:
  • User pools — user directory and authentication
  • Identity pools (federated identities) — exchange IdP tokens for temporary AWS credentials so users can access AWS services directly
Understanding when to use each is important for designing secure architectures and for the AWS Solutions Architect Associate exam: AWS Solutions Architect Associate Certification.
A "Benefits" slide with five numbered panels, each showing a colored circular icon and a short label. The items are: Secure Password Storage; Integration With Identity Providers; Quick Start‑up; Pay‑as‑You‑Go; and Scalable.

​
User pools

A Cognito user pool is a fully managed user directory. It handles user registration, sign-in, account recovery, password policies, email/SMS verification, MFA, and session management. When a user authenticates, the user pool issues standard OAuth 2.0 / OpenID Connect tokens (JWTs): an ID token, an access token, and a refresh token. Your application validates these JWTs and enforces authorization based on their claims (scopes, groups, custom claims). Typical user pool flow:
  1. The user signs up or signs in using the Cognito Hosted UI or your app with Cognito SDKs.
  2. The Cognito user pool authenticates the user (or delegates to a federated social/enterprise IdP) and returns JWT tokens.
  3. The client (web/mobile) sends the token with API requests (e.g., to API Gateway).
  4. The backend verifies the token (validate signature and claims) and authorizes the request.
The token is proof of authentication; your backend remains responsible for authorization decisions.
A diagram titled "Cognito User Pools – Serverless App With API Gateway" showing users authenticating with an AWS Cognito User Pool. It illustrates the flow of identity/access tokens to API Gateway, then to a Lambda function and DynamoDB.
Tokens overview Always validate JWT signatures and inspect claims like exp, iss, aud, and custom claims before granting access.

​
Identity pools (Cognito Federated Identities)

Identity pools allow applications to obtain temporary AWS credentials for authenticated (and optionally unauthenticated) users so they can call AWS services directly (for example, upload to S3 or access AppSync). Identity pools do not manage usernames or passwords; instead, they accept tokens from identity providers (Cognito user pools, social providers, SAML/OIDC) and use STS (AssumeRoleWithWebIdentity) to exchange those tokens for short-lived AWS credentials. Typical identity pool flow:
  1. The user authenticates with a user pool or external IdP and receives a JWT.
  2. The client presents that JWT to the Cognito identity pool.
  3. The identity pool validates the token and calls STS to assume an IAM role, returning temporary credentials (Access Key ID, Secret Access Key, Session Token).
  4. The client uses those temporary credentials to access AWS resources directly.
Identity pools support role mapping so you can assign different IAM roles and permissions to authenticated vs. unauthenticated users or to different user groups. This allows fine-grained control of direct AWS access from clients.
A diagram titled "Cognito Identity Pools" showing a mobile/web app interacting with Cognito user pools and social identity providers (Google and Apple). It shows login/token flows and the exchange of tokens for temporary AWS credentials to allow direct access to AWS.

​
Key distinctions (summary)

Exam tip: Use Cognito User Pools for application authentication (they issue JWTs). Use Identity Pools when clients need to access AWS resources directly (S3 uploads, DynamoDB, AppSync). The identity pool exchanges IdP tokens via STS using AssumeRoleWithWebIdentity to issue temporary credentials.

​
Additional features and implementation notes

  • Federated sign-in: User pools can federate with social IdPs (Google, Facebook, Apple) and enterprise IdPs via SAML/OIDC.
  • Hosted UI: Cognito provides a customizable hosted sign-in and sign-up UI for quick integration.
  • MFA and security: User pools support SMS or TOTP MFA and configurable password policies.
  • Role mapping: Identity pools can map token claims to IAM roles to control permissions.
  • Token management: Validate JWTs on the server and use refresh tokens to keep user sessions active without re-prompting for credentials.
When designing an architecture, choose user pools for authentication and token issuance, and add identity pools only when your client must access AWS services directly. This separation of responsibilities reduces risk by avoiding long-lived credentials on the client.

Watch Video