Skip to main content

Cognito Overview

Scaling up your authentication architecture to support massive web and mobile apps means stepping out of the standard IAM scope and jumping straight into Amazon Cognito. 🏎️🛡️

When you are building customer-facing apps, you don't want to create real AWS IAM users for millions of random people browsing your store or playing your mobile games. IAM is explicitly for internal infrastructure, employees, and automated services. Cognito handles the massive web of external, public identity management completely outside your core account.

Key Takeaways​

Let’s explore the two major sub-components of Cognito and see how they partition Authentication vs. Authorization.

🏛️ The Two Pillars of Amazon Cognito​

Cognito is cleanly divided into two completely separate engines that solve two distinct cryptographic problems:

👥 AMAZON COGNITO SECURITY MATRIX:
   ├── 🔑 1. Cognito User Pools (CUP) ──► IDENTITY PROVIDER (Who are you? / Authentication)
   └── 🪪 2. Cognito Identity Pools     ──► RESOURCE AUTHORIZER (What can you touch? / Authorization)

🔑 Pillar A: Cognito User Pools (CUP) — Authentication​

Think of a User Pool as a fully managed, scalable user directory cloud cluster. It handles the entire overhead of sign-up pages, sign-in flows, password recovery, and Multi-Factor Authentication (MFA).

  • The Federated Handshake 🤝: Users can register directly inside your custom directory, or log in via social identity providers (like Google, Facebook, Apple) or corporate systems using OIDC and SAML protocols.
  • The Output Tokens: When a user logs in successfully, the User Pool hands your front-end application a standard set of JSON Web Tokens (JWTs)—specifically Identity, Access, and Refresh tokens.
  • Best-Friend Integrations: These JWTs integrate natively with Amazon API Gateway (using a built-in Cognito Authorizer) and the Application Load Balancer (ALB) to securely lock down your serverless microservices and web routing lines.

🪪 Pillar B: Cognito Identity Pools (Federated Identities) — Authorization​

An Identity Pool has no user directory profile database of its own. Its entire job in the cloud is to take an identity token coming from an authentication provider (like a Cognito User Pool, Facebook login, or an anonymous guest session) and exchange it for short-lived, temporary AWS IAM credentials (via AWS STS).

  • Direct Resource Access 📂: This allows your mobile app or web client to bypass your backend servers entirely and read or write files straight out of a private Amazon S3 bucket, or write tracking logs straight into a DynamoDB table using its own temporary, restricted IAM roles!

🚨 THE VITAL EXAM TRAP: User Pools vs. Identity Pools 🚨​

This is a recurring high-priority scenario check on the blueprint. Do not mix up the exact handoffs:

  • User Pools give you JWT Tokens. You use these standard web tokens to talk to APIs that YOU built (like routes fronted by API Gateway or AWS AppSync).
  • Identity Pools give you temporary AWS IAM Security Credentials (STS). You use these access keys to execute requests against APIs that AWS built (like reading an object via S3 APIs or updating a document via DynamoDB APIs)!

Exam Tips​

  • The Mass Mobile App Catch: If an exam prompt introduces a new public mobile puzzle game or e-commerce storefront, and mentions supporting "hundreds of thousands of social media logins" or "adding standard custom attribute sign-up verification gates without maintaining a database infrastructure"—look straight for deploying an Amazon Cognito User Pool.
  • The Guest Upload S3 Bypass: If a scenario presents a rule where unauthenticated anonymous guest users need the ability to securely stream game metric files directly up into a private Amazon S3 staging bucket—choose the answer that leverages a Cognito Identity Pool configured with "Enable access to unauthenticated identities" to dispense highly restricted guest IAM roles.