AWS Cognito
AWS Cognito is a fully managed customer identity and access management (CIAM) service. It provides developers with a scalable backend framework to add user registration, sign-in, multi-factor authentication, and access control to web and mobile applications.
Instead of writing custom database tables to store password hashes, manually handling JSON Web Tokens (JWTs), or building complex OAuth 2.0 flow states from scratch, you delegate the entire identity lifecycle to this service.
1. The Two Primary Components
The architecture is divided into two distinct sub-services. They handle separate parts of the authentication and authorization lifecycle and can be used independently or together.
User Pools
A User Pool is a secure user directory that handles user onboarding, profile storage, and authentication.
Primary Function: It verifies who a user is (Authentication).
Core Capabilities: It manages standard sign-up forms, handles password strength enforcement, tracks multi-factor authentication (MFA) codes, and runs account recovery workflows (such as forgotten passwords).
The Output: Upon successful verification, the User Pool issues standardized JSON Web Tokens (JWTs)—specifically an ID Token, an Access Token, and a Refresh Token—conforming to OpenID Connect (OIDC) standards.
Identity Federation: It allows users to log in directly via an email and password, or federate through social providers (such as Google or Apple) and corporate identity systems (via SAML 2.0 or standard OIDC).
Identity Pools
An Identity Pool (also known as Federated Identities) is a credential broker that does not store user accounts or passwords. Its sole job is to trade an identity token for temporary security credentials.
Primary Function: It determines what a user can access (Authorization).
Core Capabilities: It intercepts tokens from an identity provider (like a Cognito User Pool, a social login, or a custom authentication backend) and exchanges that token for short-lived, temporary AWS IAM credentials (an Access Key ID, Secret Access Key, and Session Token).
Direct Resource Access: This allows frontend applications to communicate directly with physical infrastructure (like uploading a profile picture straight to an S3 bucket or reading a notification stream from a NoSQL database) without routing every single file payload through a custom API server.
2. Standard Authentication Workflow
When combining both components to protect a modern application architecture, the authorization sequence follows a highly structured, state-driven pattern:
[ Frontend App ] -- 1. Credentials --> [ User Pool ]
[ Frontend App ] <-- 2. JWT Tokens ---- [ User Pool ]
[ Frontend App ] -- 3. Pass JWT -----> [ Identity Pool ]
[ Frontend App ] <-- 4. IAM Creds ----- [ Identity Pool ]
[ Frontend App ] -- 5. Direct Access -> [ AWS S3 / DynamoDB ]
Step 1: The user enters their email and password into the frontend web interface. The frontend application transmits these credentials directly to the User Pool.
Step 2: The User Pool validates the credentials. If correct, it generates and returns a cryptographically signed set of JWT tokens (ID, Access, and Refresh) back to the application client.
Step 3: The frontend application catches the JWT tokens and forwards the ID token to the Identity Pool to prove it represents a valid, authenticated user.
Step 4: The Identity Pool inspects the cryptographic signature of the token to confirm it is authentic. It then reaches out to the IAM service to pull temporary, short-lived infrastructure credentials mapped to that user's specific application role.
Step 5: The frontend application utilizes those temporary credentials to write data, read objects, or call regional backend resources directly.
3. Customizing Lifecycles via Compute Triggers
To prevent identity management from becoming rigid, you can inject serverless code execution blocks directly into different stages of the registration and login pipelines. This is handled by configuring specific code hooks:
Pre Sign-up Trigger
Runs custom validation checks before a user account is officially created in the directory. You can use this to programmatically inspect incoming registration data, block temporary or disposable email domains, or enforce custom business validation rules before allowing a registration to complete.
Pre Token Generation Trigger
Executes immediately after a user successfully validates their password, but just before the final JSON Web Token is securely minted and signed. This allows your backend application to dynamically append custom claims, injection arrays, or application roles directly into the payload of the JWT access token.
User Migration Trigger
Enables seamless user onboarding when transitioning away from a legacy database or a custom hashing infrastructure. When an existing user attempts to log in with their old password, this trigger fires, intercepts the plaintext input, validates it securely against your legacy database api, and transparently creates the new account profile in the managed user directory without forcing the end user to reset their password.