Here is a summary of must know items on Amazon Cognito—concepts, features, tips, and gotchas:
Amazon Cognito provides authentication, authorization, and user management for web and mobile apps.
It has two main parts: User Pools (auth users) and Identity Pools (get AWS credentials).
User Pools are managed user directories with sign-up and sign-in flows.
Identity Pools (a.k.a. Federated Identities) exchange identities for temporary AWS credentials via STS.
You can use User Pools alone for app auth without touching AWS credentials.
Use Identity Pools when your app must call AWS services directly from the client.
User Pools support OAuth 2.0 flows (Authorization Code, Implicit, Client Credentials).
Hosted UI gives a ready-made login page with minimal setup.
You can bring a custom domain for the Hosted UI via ACM.
PKCE is supported and recommended for public/native clients.
User Pools issue OIDC-compatible JWTs: ID token, access token, and refresh token.
Tokens are signed with a rotating RSA key; verify with the JWKs endpoint.
The ID token carries user profile claims (like email, sub, custom attributes).
The access token authorizes calls to the Cognito User Pools API and custom scopes.
The refresh token lets clients obtain new ID/access tokens without re-login.
Refresh token lifetime is configurable (hours to days); choose conservatively.
Access token defaults are short-lived for better security.
MFA can be optional or required per user or per pool.
MFA factors include SMS and TOTP (software token).
Adaptive authentication can challenge high-risk sign-ins automatically.
Lambda triggers let you customize almost every step of the auth journey.
Pre Sign-up trigger can auto-confirm or auto-verify users.
Custom Message trigger customizes email/SMS content for OTPs and invites.
Post Confirmation trigger runs after a user is confirmed.
Pre Authentication trigger can block logins based on policy.
Post Authentication trigger is useful for logging and analytics.
Define/Auth/Verify Challenge triggers implement custom auth (e.g., passwordless).
Pre Token Generation trigger can add or filter JWT claims.
User Migration trigger imports users on-the-fly from legacy identity stores.
Token revocation is available to proactively invalidate refresh tokens.
App clients represent applications and define allowed auth flows and callbacks.
Public clients should NOT keep a client secret; use PKCE instead.
Confidential clients (secure backends) can use client secrets.
Callback and sign-out URLs must be whitelisted in the app client.
Scopes control what data and APIs the tokens authorize.
The standard OIDC scopes are openid, email, phone, and profile.
You can define custom resource servers and custom scopes in a User Pool.
Users can belong to groups for role-based access control.
Group membership can appear in the ID token as custom claims.
Admin APIs allow user management without the user’s password.
AdminCreateUser can create users and send temporary passwords.
AdminInitiateAuth authenticates users programmatically.
ChangePassword and ForgotPassword flows are available via SDK and Hosted UI.
Global sign-out invalidates refresh tokens for the user.
Device remembering can reduce MFA prompts on trusted devices.
Account recovery supports email, phone, or both.
Email verification is strongly recommended to reduce fraud.
Phone verification uses SMS and incurs messaging costs.
Advanced security features detect compromised credentials.
You can block sign-ins with leaked passwords automatically.
User Pool attributes include standard and custom attributes.
Custom attributes can be mutable or read-only.
Attribute verification adds trust to claims like email and phone_number.
Password policies enforce length, complexity, and reuse rules.
Temporary passwords force a password change at first login.
SRP (Secure Remote Password) protects passwords during authentication.
Cognito supports SAML 2.0 identity providers for enterprise SSO.
Cognito supports OIDC identity providers for modern IdPs.
Social providers (Google, Apple, Facebook, Amazon) are built in.
With social/SAML/OIDC IdPs, Cognito becomes a broker to your app.
Federation can be through User Pools (OIDC/SAML) or Identity Pools.
Identity Pools can map users to different IAM roles based on rules.
Role mapping can use token claims like groups or custom attributes.
Unauthenticated (guest) identities can be enabled cautiously.
Always scope IAM permissions to the minimum needed.
Identity Pools cache AWSSDK credentials and refresh when near expiry.
Use CloudWatch metrics and logs to monitor sign-ins and errors.
CloudTrail records administrative API calls for auditing.
Cognito integrates with AWS WAF when fronted by CloudFront/ALB patterns.
The Hosted UI can be themed lightly; deep customization needs your own UI.
Cognito supports custom authentication flows for passwordless magic links or OTP.
Email sending uses SES by default or shared Cognito email; verify limits.
For high-volume email, configure your own SES identity and dedicated configuration.
SMS sending relies on Amazon SNS; costs vary by country.
Consider local regulations for OTP messaging and data residency.
User Pool data is region-scoped; choose regions near users.
Export users via the CLI or APIs with appropriate permissions.
Import users using CSV with AdminCreateUser or migration triggers.
For zero-downtime migrations, the User Migration trigger is ideal.
Token audiences (aud) must match your app client ID or resource server.
Validate tokens by checking signature, issuer, audience, and expiration.
The issuer (iss) is your pool’s OIDC discovery endpoint.
JWKS are published under /.well-known/jwks.json for each pool.
Cache JWKs to avoid repeated network calls in your backends.
Use libraries like AWS JWT Verify (or jose) to validate tokens.
Rotate app secrets and monitor for leakage.
Don’t store long-lived refresh tokens in browser localStorage.
Prefer httpOnly, secure cookies for web token storage.
On SPAs, pair Authorization Code + PKCE with cookie-based sessions on the backend.
Cognito pricing is based on MAUs, messages, and advanced security usage.
Identity Pools use STS which has its own limits and quotas.
Rate limits apply to Cognito APIs; implement retries with backoff.
Test sign-in flows on slow networks and mobile devices early.
Keep callback URLs exact; mismatches cause opaque OAuth errors.
Confirm that time sync (NTP) is correct; token validation is time-sensitive.
For Apple Sign-In, set services IDs and key properly; test on iOS/macOS.
For Google Sign-In, configure OAuth consent screen and redirect URIs precisely.
Use separate user pools and clients for dev, staging, and prod.
Document your attribute schema and mapping from external IdPs.
Start simple with Hosted UI + Code + PKCE, then layer in federation, MFA, and custom triggers as needed.
AWS Skill Builder offers hundreds of free digital courses, including those related to AWS security and identity services. You can check for Cognito-specific modules as well.Amazon Web Services, Inc.
AWS also provides developer guides, workshops, tutorials, and “Getting Started” pages for Cognito (user pools, identity pools, etc.)—accessible via their official documentation.Amazon Web Services, Inc.AWS Workshops
Additionally, AWS blogs sometimes highlight Cognito-focused content or new training offerings.Amazon Web Services, Inc.
The “AWS Identity and Access Management – Cognito Getting Started” course by Tutorials Dojo includes presentations, videos, and knowledge checks.
Covers Cognito basics, architecture, use cases, user and identity pool setup via the AWS Console, and cost structures.
Free and includes a completion certificate.Tutorials Dojo
A comprehensive YouTube course titled “Learn AWS Cognito for Authentication” by freeCodeCamp:
Covers User Pools vs Identity Pools vs IAM
OAuth 2.0 workflows, JWTs, API security
Integrates Cognito with React, Node.js, and AWS API Gateway
Tutorial project: Build a secure file-sharing app using Cognito, S3, and React
Entirely free and hands-on.FreeCodeCamp
freeCodeCamp also has written coverage of this YouTube course if you prefer reading or want a quick summary.FreeCodeCamp
DataCamp offers a written guide on AWS Cognito’s architecture, identity models, common use cases, and best practices—updated recently (August 2025).DataCamp
Frontegg’s guide walks through setting up User Pools, features, and a quick tutorial with setup steps.Frontegg
Plenty of other blog posts and tutorials exist for deeper dives (e.g., TSH blog, DigitalCloud cheat sheets).The Software HouseDigital Cloud Training
Learning Type
Resource
Highlights
Official AWS
AWS Skill Builder & Docs
Structured, hands-on, free
Guided Intro Course
Tutorials Dojo Course
Beginner-friendly, certificate
Video Course
freeCodeCamp YouTube
Deep dive, project-based
Written Tutorials
DataCamp, Frontegg, blogs
Great for quick reference or detailed study
Recommended path:
Start with AWS Skill Builder to get official hands-on basics.
Follow the Tutorials Dojo course to reinforce learnings with structure.
Watch the freeCodeCamp YouTube series for a full, real-world build experience.
Use guides like DataCamp or Frontegg for reference or deeper understanding along the way.
1.1 What is the main purpose of the mobile app?
1.2 Who are the primary users (customers, employees, partners)?
1.3 Which markets/regions will the app serve?
1.4 Do we need multi-tenancy support (e.g., different organizations)?
1.5 What are the key business KPIs linked to authentication?
1.6 Do we need loyalty program integration with Cognito?
1.7 How important is speed to market vs. long-term scalability?
1.8 Are there cost constraints for authentication & identity services?
1.9 Will user experience (UX) be more important than strict security?
1.10 Is federated login a must-have for launch or a future phase?
2.1 What user types do we need (customers, staff, admins)?
2.2 Will different roles need different sign-up flows?
2.3 Should guest/anonymous accounts be supported?
2.4 How should admin users authenticate?
2.5 Do users require elevated permissions (tiered access)?
2.6 Should loyalty program tiers map to Cognito groups?
2.7 Do we need temporary accounts (trial users)?
2.8 Will there be child/linked accounts (e.g., family)?
2.9 How should deleted users be handled?
2.10 Will dormant accounts be auto-disabled?
3.1 Do we need email or phone-based signup?
3.2 Will social logins (Google, Facebook, Apple, etc.) be supported?
3.3 Is enterprise SSO (SAML, OIDC) required?
3.4 Do we need magic links or passwordless login?
3.5 Will MFA (Multi-Factor Authentication) be mandatory?
3.6 Should MFA be SMS, TOTP (Google Authenticator), or push-based?
3.7 How should failed login attempts be handled?
3.8 Do we allow users to change their usernames?
3.9 Should users verify email/phone before first login?
3.10 Do we need custom authentication challenges (e.g., KYC)?
4.1 What compliance standards apply (GDPR, POPIA, HIPAA, PCI DSS)?
4.2 Should data at rest be encrypted with customer-managed keys?
4.3 Do we need IP allow/deny lists?
4.4 Should session tokens expire quickly (short-lived) or long-lived?
4.5 Do we need fine-grained access control via Cognito groups?
4.6 Should we enable adaptive authentication (risk-based)?
4.7 How will we handle password strength enforcement?
4.8 Do we need account lockouts after repeated failures?
4.9 Should admins have just-in-time access (temporary)?
4.10 How should audit logs be retained and stored?
5.1 Should sign-up be single-step or multi-step (progressive profiling)?
5.2 Should users choose usernames or auto-generate them?
5.3 How should we handle forgotten passwords?
5.4 Should login errors be vague (security) or specific (UX)?
5.5 Do we need branded hosted UI or custom UI?
5.6 Will users authenticate via deep links (app links)?
5.7 Do we require biometric login (FaceID, TouchID)?
5.8 Should we support offline authentication (cached tokens)?
5.9 Do we allow multiple devices per user?
5.10 Should sessions be terminated on logout across devices?
6.1 Should we enable Google, Apple, and Facebook login?
6.2 Do we need LinkedIn or Twitter login for referrals?
6.3 Should enterprise partners authenticate with SAML?
6.4 Do we need integration with Microsoft Azure AD?
6.5 Should user data sync across loyalty partners’ systems?
6.6 Do we need Just-In-Time (JIT) user provisioning?
6.7 Will external identity providers require attribute mapping?
6.8 Should social login users be merged with email accounts?
6.9 Do we need step-up authentication when switching roles?
6.10 Should we support government IDs or eIDAS login?
7.1 What attributes are required at sign-up (name, email, phone)?
7.2 Should custom attributes be stored (loyalty number, tier)?
7.3 Do we need to encrypt sensitive attributes (e.g., ID numbers)?
7.4 Will attributes change based on user role?
7.5 Should user consents be captured in Cognito attributes?
7.6 Do we need dynamic attributes from external APIs?
7.7 How should attribute updates be handled (self-service vs admin)?
7.8 Should we store marketing preferences?
7.9 Do we need attribute validation (regex, business rules)?
7.10 Should attributes be synced to CRM or ERP?
8.1 What token expiration policy should we use (ID, access, refresh)?
8.2 Do we need silent refresh of tokens?
8.3 Should tokens include custom claims (loyalty tier)?
8.4 Should we use Cognito Identity Pools for AWS service access?
8.5 Do we need cross-device session persistence?
8.6 Should logout revoke refresh tokens immediately?
8.7 Will mobile apps store tokens in secure storage (Keychain/Keystore)?
8.8 Should we log and alert for suspicious token use?
8.9 Do we need delegated access (on behalf of another user)?
8.10 Should sessions survive app reinstalls?
9.1 Which SDKs will we use (AWS Amplify, native SDKs)?
9.2 Should we allow direct API calls or only via API Gateway?
9.3 Do we need Cognito triggers (Lambda functions)?
9.4 What pre-sign-up validations are required?
9.5 Should we use custom authentication challenges?
9.6 Do we need migration triggers from an old auth system?
9.7 Will front-end devs manage Cognito configs via Amplify CLI?
9.8 Should we test auth flows with automated UI tests?
9.9 Do we need integration testing with partner systems?
9.10 Should we create a mock identity provider for testing?
10.1 Should CloudWatch monitor all Cognito events?
10.2 Do we need custom dashboards (Grafana, Datadog)?
10.3 How often should we review access logs?
10.4 Do we need alerts for failed login spikes?
10.5 Should admins be notified of suspicious activity?
10.6 Should we track user churn from login data?
10.7 Do we need SLA-based reporting for uptime?
10.8 Should we audit API throttling events?
10.9 Do we need automated account cleanup?
10.10 Should post-deployment load testing include Cognito flows?
1.1 Should we use SRP (Secure Remote Password) protocol for extra safety?
1.2 Do we need adaptive authentication (location/device-based)?
1.3 Should we allow device-based remembered MFA?
1.4 Should MFA enrollment be optional or mandatory at first login?
1.5 Do we need custom challenges (e.g., one-time loyalty PIN)?
1.6 Should we integrate fraud detection tools (e.g., Amazon Fraud Detector)?
1.7 Will login attempts from TOR/VPNs be blocked?
1.8 Do we need CAPTCHAs during suspicious signups?
1.9 Should biometric login be combined with Cognito tokens?
1.10 Do we need passwordless flows (FIDO2/WebAuthn)?
2.1 How many monthly active users are expected?
2.2 What’s the peak concurrent login volume?
2.3 Should we pre-warm Cognito for large events (campaign launches)?
2.4 Do we need global sign-in performance optimization?
2.5 Should we use CloudFront to cache hosted UI assets?
2.6 Do we need latency benchmarks across regions?
2.7 Will Cognito scale with burst traffic (e.g., flash sales)?
2.8 Should we partition user pools by geography?
2.9 Do we need dedicated infrastructure (instead of shared)?
2.10 Should we design for 1M+ users in the loyalty program?
3.1 Should Cognito user pools be replicated across regions?
3.2 Do we need active-active multi-region authentication?
3.3 Should failover to another region be automated?
3.4 Will DNS failover (Route 53) be used for auth endpoints?
3.5 Do we need global sign-out across regions?
3.6 Should user attributes sync between regions in real-time?
3.7 How will outages in one region affect users globally?
3.8 Should we use Amazon Global Accelerator for sign-in routing?
3.9 Do we need regional GDPR/POPIA compliance separation?
3.10 Should we test region failover regularly?
4.1 Do we need temporary AWS credentials for mobile users?
4.2 Should identity pools map roles per loyalty tier?
4.3 Do we allow direct S3 access via Cognito Identity Pools?
4.4 Will users access AWS IoT services via Cognito?
4.5 Should we integrate Cognito with API Gateway IAM authorizers?
4.6 Do we need cross-account IAM role assumption?
4.7 Should Lambda functions impersonate users?
4.8 Do we restrict AWS service access based on Cognito groups?
4.9 Do we need Cognito + AppSync integration for GraphQL?
4.10 Will we expose AWS services directly to authenticated users?
5.1 Do we need to import users from an existing database?
5.2 Should password hashes be migrated (SRP compatibility)?
5.3 Do we support seamless migration during first login?
5.4 Will legacy loyalty IDs need to be linked to Cognito accounts?
5.5 Should we provide bulk account migration APIs?
5.6 Do we need backward compatibility with an old app?
5.7 How do we handle duplicate users during migration?
5.8 Should migration respect original signup dates?
5.9 Do we need audit logs for migrated accounts?
5.10 Should migration be phased (pilot vs big bang)?
6.1 How long should deleted user data be retained?
6.2 Should anonymized data be stored for analytics?
6.3 Do we need explicit user consent tracking?
6.4 Should user consents be revocable via self-service?
6.5 Do we need data residency guarantees (e.g., EU only)?
6.6 Will loyalty points be deleted when an account is erased?
6.7 Do we need legal hold on user data (litigation)?
6.8 Should we support “Download My Data” requests?
6.9 Do we need fine-grained audit of data access?
6.10 Should attributes like birthdate be encrypted separately?
7.1 Should we use AWS WAF in front of the Cognito Hosted UI?
7.2 Do we need DDoS mitigation for login endpoints?
7.3 Should sign-in attempts trigger GuardDuty alerts?
7.4 Do we need custom Lambda checks for risky logins?
7.5 Should we enforce TLS mutual authentication?
7.6 Do we need HSM-backed encryption for tokens?
7.7 Should we require SCIM for enterprise provisioning?
7.8 Do we need per-device tokens (device fingerprinting)?
7.9 Should we integrate with AWS Secrets Manager?
7.10 Do we need zero-trust integration with API Gateway?
8.1 Should we fully customize the Cognito hosted UI?
8.2 Do we need white-label branding for partners?
8.3 Should the signup flow be themed per loyalty tier?
8.4 Do we need different domains for different regions?
8.5 Should loyalty campaigns have custom sign-up flows?
8.6 Will we allow QR-based signup at physical stores?
8.7 Do we need embedded widgets (e.g., loyalty points in POS)?
8.8 Should Cognito emails be branded with company templates?
8.9 Do we need SMS OTP branding (alphanumeric sender ID)?
8.10 Will loyalty partners require co-branded login screens?
9.1 Should login failures trigger CloudWatch alarms?
9.2 Do we need integration with SIEM (Splunk, ELK)?
9.3 Should we track authentication success/failure ratios?
9.4 Do we log social vs. native login adoption?
9.5 Do we track device distribution in Cognito logs?
9.6 Should suspicious logins be escalated to SOC teams?
9.7 Do we need to export logs to S3 for analytics?
9.8 Should we track churn from inactive Cognito users?
9.9 Do we need monthly Cognito usage cost reports?
9.10 Should loyalty team dashboards include login analytics?
10.1 Who owns Cognito configuration (IT or product team)?
10.2 Should changes be controlled via IaC (Terraform/CloudFormation)?
10.3 Do we need environment separation (dev, test, prod pools)?
10.4 Should user pool schema changes require approval workflows?
10.5 Who manages social identity provider keys?
10.6 Should Cognito configs be peer-reviewed like code?
10.7 Do we need quarterly security posture reviews?
10.8 Should loyalty partners have delegated admin access?
10.9 Do we plan feature rollouts with Cognito advanced security?
10.10 What’s the 3-year roadmap for identity management?
User Pool – A secure user directory where app users are created, authenticated, and managed.
Identity Pool (Federated Identities) – Provides AWS service access via temporary credentials for authenticated users.
Hosted UI – Cognito’s ready-made login/signup web interface (can be customized).
MFA (Multi-Factor Authentication) – Adds extra security by requiring SMS, TOTP (Authenticator app), or push verification.
Access Token – JWT token used to authorize access to APIs.
ID Token – JWT token containing user identity details (name, email, attributes).
Refresh Token – Long-lived token used to get new access/ID tokens without logging in again.
Attributes – User data stored in Cognito (e.g., email, phone, loyalty number).
App Client – Represents your app in Cognito; defines token settings, callback URLs, etc.
Sign-up / Sign-in Flow – The process Cognito uses for user registration and authentication.
Custom Attributes – Extra fields (like loyalty tier) you add to user profiles.
Groups – Logical user categories (e.g., Silver, Gold, Admin) with different permissions.
Roles (IAM Roles) – Define what AWS resources users can access after authentication.
Triggers – Lambda functions you attach to Cognito events (pre-signup, post-authentication, etc.).
Hosted Domains – Cognito’s default domain (or custom one) for Hosted UI.
User Pool Client Secret – Optional secret key for app-to-Cognito authentication (not used on mobile apps).
SRP (Secure Remote Password protocol) – Protocol Cognito uses for secure password authentication.
Password Policy – Rules for password strength (length, special characters, etc.).
Advanced Security Features – Cognito option for adaptive authentication (risk-based login).
Temporary AWS Credentials – Issued by Identity Pools so users can securely use AWS resources.
Federated Identity Provider (IdP) – External service for login (Google, Apple, Facebook, SAML, OIDC).
OIDC (OpenID Connect) – Protocol Cognito uses to integrate with third-party IdPs.
SAML 2.0 – Standard for enterprise single sign-on (SSO) integration with corporate IdPs.
SCIM (System for Cross-domain Identity Management) – Standard for automatic user provisioning between systems.
Just-in-Time (JIT) Provisioning – Auto-creating a user in Cognito at first login from an external IdP.
Attribute Mapping – Matching IdP attributes (like “email”) with Cognito user attributes.
Social Sign-In – Login via social accounts (Google, Facebook, Apple).
Enterprise Federation – Login via corporate IdPs (Azure AD, Okta, Ping).
Linked Identity – When one user has multiple logins (social + email) merged.
Access Control with Groups/Roles – Mapping external IdP groups to Cognito roles.
JWT (JSON Web Token) – Format used by Cognito tokens (access, ID, refresh).
Token Expiration – Duration a token is valid (access: short, refresh: longer).
Global Sign-Out – Logs a user out across all devices.
Revocation – Invalidating tokens before their expiration.
Device Remembering – Cognito’s ability to track known devices for users.
Custom Authentication Challenge – Extra steps (e.g., loyalty PIN) in login flow.
Adaptive Authentication – Risk-based MFA requirement (based on IP, device, behavior).
Account Recovery – How users reset passwords or unlock accounts.
Audit Logs – Tracking user auth events (CloudTrail, CloudWatch).
Least Privilege Principle – Assigning only minimal permissions to Cognito roles.
AWS Amplify – Developer toolkit that simplifies using Cognito in apps.
Amplify Auth – Amplify module for authentication with Cognito.
Admin SDK – Tools for managing users programmatically.
Cognito CLI – Command-line setup and management of Cognito pools.
PostConfirmation Trigger – Lambda that runs after user signup to customize flow.
PreSignUp Trigger – Lambda that validates/auto-confirms sign-ups.
PreTokenGeneration Trigger – Lambda that customizes token claims before delivery.
Migration Trigger – Used for migrating users from another identity provider.
Custom Message Trigger – Customizes signup/verification emails & SMS.
Sync (Deprecated) – Old Cognito feature for syncing user data across devices.
User Pool Domain – Default Cognito login domain or custom subdomain.
Hosted UI Callback URL – Where Cognito sends users after login/logout.
Implicit vs. Authorization Code Flow – OAuth flows supported in Cognito.
Refresh Token Expiry – Can last from 1 day to 10 years.
Access Token Scope – Defines what APIs a user can call.
Custom Scopes – Developer-defined scopes for fine-grained API access.
Token Revocation Endpoint – API to invalidate refresh tokens.
Cognito Identity vs User Pool – Difference between authentication and AWS resource authorization.
AWS AppSync Integration – Cognito as an auth provider for GraphQL APIs.
GuardDuty/CloudWatch Integration – Using Cognito logs in monitoring tools.
Priority summary:
Know 1–10 cold (fundamentals).
Understand 11–20 for implementation.
Grasp 21–30 when integrating with partners/social/enterprise.
Learn 31–40 to cover security & compliance.
Use 41–50 if you’re building with Amplify or doing advanced customization.
Explore 51–60 once you’re scaling and operating Cognito long-term.
Here’s a 1-week (5-day, full-time) training course outline that takes someone from intermediate knowledge to AWS Cognito Subject Matter Expert (SME) level. The course balances theory, hands-on labs, architecture design, and troubleshooting.
Objective: Build a solid understanding of Cognito fundamentals and integration in mobile/web apps.
Module 1: Introduction to Identity & Access Management
IAM vs Cognito: Roles, Differences, Use Cases
Cognito in the AWS ecosystem (API Gateway, AppSync, Amplify, Lambda)
Module 2: Cognito Basics
User Pools vs Identity Pools
Authentication vs Authorization
Key Cognito terminology (Tokens, Claims, Flows)
Lab 1: Create a User Pool and register/login a user via AWS Console.
Lab 2: Enable MFA and password policies.
Objective: Deep dive into how users authenticate and secure the app.
Module 3: Authentication Flows
SRP (Secure Remote Password) flow
OAuth 2.0 (Authorization Code, Implicit, Client Credentials)
Hosted UI vs Custom UI flows
Module 4: Security & Compliance
JWT (ID, Access, Refresh tokens)
Token expiration & refresh strategies
Protecting APIs with Cognito (API Gateway authorizers)
Lab 3: Build a mobile app login flow using Amplify + Cognito Hosted UI.
Lab 4: Secure an API Gateway endpoint with Cognito authorizer.
Objective: Become an expert in managing users, attributes, and custom logic.
Module 5: User Management & Attributes
Standard vs Custom attributes
Attribute mapping with Identity Pools
Account recovery & password reset flows
Module 6: Triggers & Lambda Customization
PreSignUp, PreAuth, PostAuth, PreTokenGen, CustomMessage
Use cases: Auto-confirm users, enrich JWT claims, custom validation
Lab 5: Implement Lambda trigger for custom signup flow (e.g., auto-confirm corporate emails).
Lab 6: Customize JWT claims for downstream API usage.
Objective: Master federated identity and enterprise SSO integration.
Module 7: Social Identity Federation
Google, Facebook, Apple sign-in integration
Linking social & native accounts
Module 8: Enterprise Federation
SAML 2.0 identity providers (Okta, ADFS, Azure AD)
OIDC providers integration
Hybrid identity strategy (User Pool + IdP)
Module 9: Cognito Identity Pools in depth
Federated access to AWS resources (IAM role mapping, role assumption)
Lab 7: Integrate Cognito with Google Sign-In.
Lab 8: Set up Cognito with an enterprise IdP (SAML/OIDC).
Objective: Become an SME by knowing how to scale, monitor, and debug Cognito.
Module 10: Scalability & Limits
Cognito quotas (users, API calls, Lambda triggers)
Multi-region and high availability setup
Module 11: Monitoring & Logging
CloudWatch metrics & logging
CloudTrail auditing Cognito API calls
Module 12: Troubleshooting & Best Practices
Common errors (NotAuthorizedException, Token issues)
Debugging sign-in failures
Designing for resilience and cost optimization
Capstone Lab:
Design and implement a production-ready Cognito setup for a mobile loyalty app:
Email + social login
MFA enabled
API Gateway secured with Cognito Authorizer
Role-based access control via JWT claims
Enterprise IdP integration
-Strong grasp of Cognito terminology and architecture
-Hands-on experience with all core and advanced features
-Ability to design enterprise-ready Cognito solutions
-Ability to troubleshoot and optimize real-world Cognito deployments
-Ready for SME-level consulting on Cognito implementations
Welcome & course overview – objectives, SME expectations
Identity management in cloud vs on-prem
IAM vs Cognito – scope and positioning in AWS ecosystem
Cognito architecture overview – User Pools & Identity Pools
Understanding Authentication vs Authorization
Cognito tokens – ID, Access, Refresh – use cases & lifetimes
Multi-tenancy concepts in Cognito (separate vs shared pools)
Cognito console deep dive – user pool setup options
Password policies & security baselines
Multi-factor authentication (MFA) – SMS, TOTP, hardware token
Account recovery & self-service flows
Lab 1: Create a Cognito User Pool with basic attributes
Lab 2: Enable MFA and test password recovery
Wrap-up discussion: positioning Cognito in mobile app stack
Deep dive: SRP (Secure Remote Password) flow
OAuth 2.0 explained in Cognito context
Supported OAuth flows: Authorization Code, Implicit, Client Credentials
Hosted UI vs custom UI login strategies
Token validation – signature, expiry, audience claim
Refresh tokens & silent authentication strategies
Protecting APIs with Cognito User Pool authorizer
Identity Pool role assumption – granting AWS service access
Role mapping: default vs fine-grained
Lab 3: Implement login with Hosted UI in a mobile app
Lab 4: Secure API Gateway endpoint with Cognito authorizer
Security considerations – token replay, token leakage
Best practices: short-lived tokens, refresh rotation
Wrap-up: Authentication patterns for B2C vs B2B apps
User lifecycle management in Cognito
Standard attributes vs custom attributes
Attribute mapping with IdPs and Identity Pools
Customizing signup flows with Lambda triggers
Triggers overview – PreSignUp, PostConfirmation, PreAuth, PostAuth, PreTokenGen, CustomMessage
Use case: auto-confirming corporate email domains
Use case: adding custom claims to ID tokens
Account migration via Lambda triggers
Security vs usability trade-offs in signup flows
Lab 5: Auto-confirm users with PreSignUp Lambda trigger
Lab 6: Add custom claims via PreTokenGen trigger
Lab 7: Customize welcome emails with CustomMessage trigger
Handling large user directories & migration strategies
Wrap-up: How SMEs optimize user flows with Cognito
What is federated identity? Core concepts
Cognito + social IdPs: Google, Facebook, Apple
Configuring OIDC providers in Cognito
Cognito & SAML 2.0 – overview and flow
Enterprise SSO with Azure AD, Okta, ADFS
Linking social and corporate identities with Cognito
Hybrid identity: mixing native Cognito users & federated IdPs
Identity Pools in depth – temporary AWS credentials via STS
IAM role mapping with IdPs – attribute-based mapping
Lab 8: Integrate Cognito with Google sign-in
Lab 9: Set up Cognito with Azure AD SAML integration
Lab 10: Map IdP attributes to IAM roles
Security implications of federation (trust boundaries)
Best practices: enterprise integration patterns
Wrap-up: Cognito in multi-cloud and enterprise scenarios
Cognito scalability model – regional service, global implications
Cognito quotas and service limits – user pools, API requests
Multi-region architectures with Cognito
Disaster recovery and backup strategies
Monitoring Cognito with CloudWatch metrics
Logging Cognito events with CloudTrail
Debugging authentication failures with CloudWatch Logs
Error codes – NotAuthorizedException, TokenExpiredException, etc.
Handling rate limits & retries in mobile apps
CI/CD integration – Infrastructure as Code (CloudFormation, CDK, Terraform)
Lab 11: Enable CloudWatch logging for Cognito events
Lab 12: Trace failed login attempts with CloudTrail
Lab 13: Automate Cognito deployment with CDK
Cost management – pricing model for active users, SMS, etc.
Performance optimization tips for mobile apps
Real-world case study: Cognito for a retail loyalty mobile app
Wrap-up: Cognito SME checklists for production deployments
Capstone briefing: Build Cognito solution for mobile loyalty app
Requirements: email login, social login, MFA
Requirement: secure backend APIs with Cognito
Requirement: integrate with corporate IdP (SAML)
Requirement: custom claims for loyalty tier (Silver/Gold/Platinum)
Requirement: password reset & self-service portal
Requirement: monitor usage & detect suspicious activity
Architecture design session – whiteboarding solution
Implementation guidance from instructor
Lab 14: Implement custom claims for loyalty tier
Lab 15: Secure API Gateway with Cognito & claims-based RBAC
Lab 16: Integrate corporate SAML IdP with user pool
Testing end-to-end login scenarios
Debugging and troubleshooting issues
Presenting solution architecture to peers
Peer review & group feedback session
Review of key Cognito concepts
Review of common pitfalls and best practices
Advanced topics – device tracking, adaptive authentication
Multi-account & multi-environment Cognito strategies
Comparing Cognito with Auth0, Okta, Azure B2C
Real-world SME responsibilities – advisory, design, troubleshooting
Building a Cognito runbook for enterprises
Mock SME Q&A session with scenario-based questions
SME knowledge check quiz & certification readiness
Closing session – becoming a Cognito SME consultant
By the end of this program, a participant can:
Architect enterprise-grade Cognito solutions
Integrate social + enterprise IdPs
Implement advanced user management with Lambda triggers
Troubleshoot issues like an AWS support engineer
Advise businesses as a Cognito Subject Matter Expert
Identity vs Access
Identity: Who you are (e.g., username, email, federated ID).
Access: What you’re allowed to do (permissions, policies).
IAM vs Cognito
IAM: For AWS users, groups, roles (administrative & AWS resources).
Cognito: For application end-users (mobile/web app authentication).
SME Note: Cognito extends IAM — think “IAM for app users.”
User Pools
Manage user directory, sign-up, sign-in, MFA.
Issues ID, Access, Refresh tokens.
Identity Pools (Federated Identities)
Exchange tokens for AWS temporary credentials.
Enables access to AWS services (S3, DynamoDB, etc.).
Tokens
ID Token: User profile & claims.
Access Token: Access to Cognito APIs (update user).
Refresh Token: Get new tokens without re-login.
SME Note: Always validate tokens on the server — don’t trust blindly.
Diagram (described):
Mobile app → Cognito User Pool → issues JWT tokens → API Gateway Authorizer → Lambda backend → AWS resources via Identity Pool.
Hosted UI: Prebuilt login page hosted by AWS.
Amplify Libraries: SDKs to integrate quickly.
Triggers: Extend functionality with Lambda at signup/login.
MFA: SMS, TOTP (Authenticator apps).
Advanced Security: Adaptive authentication (risk-based).
Password Policies: Length, complexity, expiry.
Account Recovery: Self-service password reset (email/SMS).
SME Note: Avoid SMS-only MFA in high-security apps — use TOTP.
Open AWS Console → Cognito → “Create User Pool.”
Choose “Email” as sign-in option.
Configure password policy: min 8 chars, require uppercase/lowercase.
Enable MFA = Optional.
Create pool & test signup with sample user.
Verify user appears in pool.
Enable MFA → Require TOTP (e.g., Google Authenticator).
Create new user & login — test MFA challenge.
Initiate password reset → check recovery flow works.
Auth0: Feature-rich, but higher cost.
Okta: Enterprise focus, deep SAML/OIDC support.
Azure AD B2C: Microsoft ecosystem.
Cognito Strengths: Tight AWS integration, lower cost.
Cognito Weaknesses: UI customization limitations, service quotas.
Cognito = identity provider for mobile/web apps.
User Pools = Authentication; Identity Pools = Authorization.
Tokens (ID, Access, Refresh) = core building blocks.
Cognito integrates seamlessly with API Gateway, AppSync, Lambda.
MFA & password policies = baseline security.
Design a signup/login flow for a retail loyalty app.
Decide: Email-only login or social login + email? Why?
Map where User Pool and Identity Pool would sit in the architecture.
Research Cognito quotas (max users, API rate limits).
End of Day 1 Content (Approx 7 hours: 4h theory + 3h labs)
Objective: Understand Cognito’s authentication flows, token management, and how to secure APIs.
SRP (Secure Remote Password) Flow
Default Cognito authentication flow.
Password never sent over the wire — mathematical exchange with server.
Resistant to replay and MITM attacks.
OAuth 2.0 Support
Cognito implements OAuth 2.0 + OpenID Connect (OIDC).
Common flows:
Authorization Code (recommended for mobile/web).
Implicit (legacy, less secure).
Client Credentials (for service-to-service auth).
Hosted UI vs Custom UI
Hosted UI: AWS-provided login screen with OAuth endpoints.
Custom UI: Build your own login using Amplify or SDKs.
SME Note: Encourage Authorization Code flow + PKCE for mobile apps.
ID Token
Contains claims (email, sub, custom attributes).
Used to identify the user.
Access Token
Grants permission to use Cognito APIs (update attributes, groups).
Refresh Token
Used to obtain new ID/Access tokens.
Default expiry: 30 days (configurable up to 365).
SME Note: Never store tokens insecurely on client (avoid local storage in web apps).
Validation Steps:
Verify JWT signature against Cognito JWKs.
Check expiry (exp claim).
Verify audience (aud) and issuer (iss).
Refresh Strategy:
Silent login using Refresh Token.
If Refresh Token expires → force re-login.
Common Pitfalls:
Using expired tokens.
Forgetting to validate signature.
Relying only on Access Token for user profile.
API Gateway Authorizer (Cognito Authorizer):
Uses Cognito User Pool tokens to allow/deny requests.
Fine-grained control via claims (e.g., only role=admin can access).
Lambda + Token Verification:
Validate JWTs manually with libraries (e.g., jsonwebtoken, aws-jwt-verify).
Identity Pools for AWS Resources:
Use token exchange to assume IAM roles.
Example: Authenticated user uploads image → gets S3 PUT permission.
In AWS Console → Cognito → User Pool → “App Clients.”
Enable Authorization Code grant with PKCE.
Configure redirect URI (e.g., http://localhost:3000/callback).
Launch Hosted UI → signup/login user.
Capture tokens (ID, Access, Refresh) in redirect URI.
Create an API Gateway REST API.
Add a /loyalty endpoint.
Configure Cognito User Pool Authorizer.
Deploy API.
Call API with:
No token → 401 Unauthorized.
Valid token → request passes.
Add claims-based rule (only users with tier=gold can access /premium).
Replay Attacks
Always validate tokens.
Keep expiry short (Access = 1 hour).
Token Leakage
Use secure storage (Keychain / Keystore / Encrypted DB).
MFA Enforcement
Can enforce MFA for all or conditional users.
Adaptive Authentication (Advanced Security)
Detect unusual sign-in (new device/location).
Challenge with MFA when risk detected.
SME Note: Adaptive Auth requires enabling Advanced Security Features.
Use Authorization Code + PKCE in mobile/web apps.
Avoid Implicit flow (deprecated).
Always validate JWTs server-side.
Store Refresh Token securely, rotate often.
Use CloudWatch/CloudTrail for suspicious login activity.
Apply least-privilege with Identity Pools → don’t give full AWS access.
Cognito supports SRP, OAuth 2.0, OIDC.
ID, Access, Refresh tokens = building blocks of auth.
Hosted UI is fastest to implement; custom UI = more flexibility.
APIs can be secured with Cognito Authorizer or manual JWT verification.
Security requires MFA, adaptive auth, and short token lifetimes.
Implement Authorization Code + PKCE flow in a test app.
Set token lifetimes: Access = 1 hr, Refresh = 7 days → test expiry.
Add claims-based authorization for two user groups (e.g., Standard vs Premium).
Research Cognito Advanced Security pricing.
End of Day 2 Content (Approx 7 hours: 3.5h theory + 3.5h labs)
Great 👍 let’s dive into Day 3 of the AWS Cognito SME Training. This day is all about advanced user management, attributes, triggers, and custom flows — the part that makes Cognito powerful for enterprise use cases.
Objective: Master user lifecycle management, custom attributes, and Lambda triggers for advanced authentication flows.
Lifecycle stages:
Signup → Verification → Login → Password resets → Account recovery → Deletion.
SME Note: Think of Cognito as a state machine — triggers let you hook into each stage.
Key Events:
Registration (create user).
Verification (email/SMS).
Authentication.
Password reset.
Account migration (legacy system → Cognito).
Standard Attributes (built-in): email, phone_number, given_name, family_name, birthdate, etc.
Custom Attributes:
Define your own schema (e.g., loyaltyTier, preferredStore).
Stored in Cognito user profile, can be mapped to IdPs.
Constraints:
Max 50 custom attributes per user pool.
Attribute name must start with custom: when used in tokens.
SME Note: Use custom claims in tokens for RBAC (e.g., custom:role=admin).
Why attribute mapping matters:
Federation → Map IdP attributes (e.g., Azure AD department) → Cognito attribute.
Identity Pools → Map Cognito attributes to IAM role assumption.
Example:
User logs in via Azure AD.
Attribute jobTitle=Manager.
Mapped to Cognito attribute custom:role=manager.
Mapped further to IAM role ManagerRole for S3/DynamoDB access.
SME Note: Attribute mapping = bridge between identity sources and AWS access.
Cognito triggers (13 total, most common ones):
PreSignUp – Auto-confirm users, validate email domains.
PostConfirmation – Send welcome email, sync data to CRM.
PreAuthentication – Add extra checks before login.
PostAuthentication – Log audit events.
PreTokenGeneration – Add custom claims to JWT.
CustomMessage – Customize emails/SMS messages.
DefineAuthChallenge – Build custom MFA logic.
CreateAuthChallenge – Issue MFA challenge (e.g., push notification).
VerifyAuthChallengeResponse – Validate custom MFA response.
SME Note: Triggers = Cognito’s customization API — they let you inject business logic.
PreSignUp: Auto-confirm @company.com users, block disposable emails.
PostConfirmation: Add new user to DynamoDB table for loyalty points.
PreAuth: Check if account is flagged as “suspended.”
PreTokenGen: Add loyaltyTier=gold claim into ID token.
CustomMessage: Brand signup emails with company logo & tone.
Account Migration: Pull users from legacy database into Cognito on first login.
Create Lambda function: check if email domain = @company.com.
If match → auto-confirm user.
If not match → reject signup.
Link Lambda to User Pool (PreSignUp trigger).
Test by signing up with test@company.com and test@gmail.com.
Create Lambda function:
Add custom:loyaltyTier claim into ID token.
Set tier = “gold” if email contains vip@.
Attach Lambda as PreTokenGen trigger.
Authenticate user → decode ID token → confirm claim is present.
Create Lambda function to override welcome email.
Include username, loyalty tier, and a custom welcome link.
Attach as CustomMessage trigger.
Signup a new user → check email formatting.
Problem: Existing users in legacy DB → how to migrate to Cognito?
Solution: PreAuth trigger queries legacy DB when user tries to login:
If found → import into Cognito → authenticate.
If not found → reject login.
SME Note: Allows “lazy migration” instead of bulk import.
Groups in Cognito:
Example: Admins, Managers, Users.
Assign users to groups → adds cognito:groups claim in token.
RBAC via Groups:
API Gateway Authorizer → check cognito:groups = Admin.
Lambda functions → check claims for fine-grained access.
SME Note: Use groups for static RBAC, use custom claims for dynamic RBAC.
Large Directories: Use Import Users tool (CSV + temporary password).
Cross-Region Users: Cognito is region-bound → consider separate pools or IdP federation.
De-provisioning: Use Lambda triggers to revoke sessions if user is disabled.
Audit: Use CloudTrail to track AdminCreateUser, AdminDisableUser.
Cognito supports both standard & custom attributes.
Attribute mapping is critical for federated IdPs.
Triggers allow deep customization (signup, login, tokens, messages).
Custom claims and groups enable RBAC at API level.
Account migration strategies make Cognito enterprise-friendly.
Implement PreSignUp trigger to auto-confirm users with company emails.
Add custom claim (subscriptionType=premium) in PreTokenGen.
Create 3 user groups (Admin, User, Manager) → test claims.
Design a migration strategy for 1 million legacy users → which triggers would you use?
End of Day 3 Content (Approx 7 hours: 4h theory + 3h labs)
Objective: Learn how Cognito integrates with key AWS services (API Gateway, AppSync, S3, DynamoDB, Lambda), enabling secure, scalable architectures.
Direct Integration
API Gateway can use Cognito User Pool Authorizers.
Validates ID/Access tokens before allowing API requests.
Use Cases
Secure REST APIs for mobile/web apps.
Claims-based routing (e.g., role-based endpoints).
Best Practices
Use fine-grained authorization with claims.
Log all 401/403 events in CloudWatch.
AppSync Authentication Modes
API Key (testing only).
Amazon Cognito User Pools.
IAM roles (via Identity Pools).
OpenID Connect providers.
Cognito Role
Provides user authentication for GraphQL queries/mutations.
Enables field-level security using groups/claims.
SME Example
Loyalty App: Standard users can query points balance.
Admins can also perform mutations like “adjustPoints.”
Identity Pools + IAM Roles
Cognito issues temporary AWS credentials.
Users get signed S3 PUT/GET access.
Use Case Examples
Profile photo upload.
Storing receipts for loyalty transactions.
Security Controls
IAM role policies tied to cognito-identity.amazonaws.com:sub.
Enforce bucket prefixes per user (/userId/*).
User Metadata Storage
Cognito User Pools store identity data (login, email, MFA).
DynamoDB stores application data (loyalty points, purchase history).
Integration Pattern
Lambda (triggered by PostConfirmation) inserts record into DynamoDB.
Example: On signup → create user profile record.
Best Practices
Keep Cognito user profile minimal.
Store business-specific data in DynamoDB.
Two Roles of Lambda in Cognito
Triggers – Customize Cognito workflows (Day 3).
Backend Services – Process authenticated requests.
Example Use Case
User logs in → gets ID Token.
Calls API Gateway → triggers Lambda.
Lambda verifies claims before performing business logic.
Security Tip
Always re-validate JWT claims inside Lambda (don’t trust only API Gateway).
Web App Authentication
Cognito integrates with CloudFront via Lambda@Edge or Cognito Auth@Edge.
Use Cases
Secure static websites hosted on S3.
Deliver personalized content per user.
Best Practices
Use signed cookies/tokens for caching efficiency.
Scenario: Loyalty Mobile App
User signs in with Cognito Hosted UI.
Receives tokens (ID, Access, Refresh).
Calls API Gateway with Access Token.
API Gateway validates token via Cognito Authorizer.
API Gateway routes request to AppSync or Lambda.
Lambda reads/writes loyalty transactions in DynamoDB.
User uploads receipts → Cognito Identity Pool → signed S3 upload URL.
Admin dashboard (web) uses same Cognito pool, but with admin group roles.
Create a new REST API in API Gateway.
Add /points GET endpoint.
Configure Cognito Authorizer with User Pool.
Deploy API.
Test with Postman:
No token → 401 Unauthorized.
Valid token → returns success JSON.
Create Identity Pool (federated identities).
Enable Authenticated role → grant s3:PutObject for mybucket/${cognito-identity.amazonaws.com:sub}/*.
Add S3 bucket policy enforcing prefix per user.
Generate credentials in mobile app via Amplify SDK.
Upload a test file to S3.
CloudTrail Logging
All Cognito events are logged (login, MFA, admin actions).
Encryption
S3 = server-side encryption (SSE-S3, SSE-KMS).
DynamoDB = encrypted at rest.
Data Residency
Cognito data tied to region.
S3 buckets must be in same region for compliance.
IAM Governance
Always use least privilege in Identity Pools.
Cognito integrates seamlessly with API Gateway, AppSync, S3, DynamoDB, and Lambda.
User Pools handle identity → Identity Pools handle AWS resource access.
Always separate authentication (Cognito) from application data (DynamoDB).
Secure file uploads with IAM policies tied to Cognito identity.
Use CloudTrail and IAM best practices to monitor integrations.
Secure a REST API with Cognito Authorizer.
Create a file upload flow with Identity Pools + S3.
Build a DynamoDB table for user profiles linked to Cognito sub.
Diagram the full architecture for a mobile loyalty app.
End of Day 4 Content (Approx 7 hours: 3h theory + 4h labs)
Objective: Master Cognito’s advanced security controls — MFA, risk-based adaptive authentication, password policies, and compliance considerations.
MFA Factors Supported
SMS-based MFA – Code sent via SMS.
TOTP (Time-Based One-Time Password) – Authenticator apps (Google Authenticator, Authy).
MFA Modes
Off – No MFA required.
Optional – User chooses whether to enable MFA.
Required – All users must use MFA.
Best Practice
Prefer TOTP (SMS is vulnerable to SIM swapping).
Steps to Enable MFA
Go to User Pool → MFA and Password policy.
Enable TOTP and/or SMS.
For SMS MFA → configure SNS role.
For TOTP → enable secret key generation.
User Experience
On first login → user sets up MFA.
On subsequent logins → challenge with MFA.
Password Policy Options
Minimum length.
Require uppercase, lowercase, numbers, symbols.
Expiry/rotation not directly supported (must use Lambda).
Account Lockout
Cognito auto-locks account after too many failed attempts.
Best Practices
Use long passwords (min 12 chars).
Combine MFA + strong password policy.
Advanced Security Features
Requires enabling Advanced Security in Cognito.
Risk Detection
Detects unusual sign-in activity (new device, location, IP).
Adaptive Responses
Allow → No challenge.
Require MFA → If risk detected.
Block → If high risk (e.g., impossible travel).
Example
User always logs in from Cape Town.
Suddenly logs in from Moscow within 2 minutes → MFA challenge triggered.
Remembered Devices
Cognito can remember devices after successful login.
User Options
“Don’t ask for MFA again on this device.”
Best Practices
Enable remembered devices with caution.
Combine with adaptive auth for strong protection.
Token Lifetime Management
Access Token: 5 min – 1 hr (default 1 hr).
Refresh Token: 1 – 365 days.
Short-Lived Tokens
Reduce risk if leaked.
SME Rule
Access Token = 1 hr.
Refresh Token = 7–30 days (based on app type).
In User Pool → MFA → select Required.
Enable TOTP MFA.
Create a new user and sign in via Hosted UI.
On first login → configure TOTP with Google Authenticator.
Test login → enter TOTP code.
Switch to SMS MFA → test again.
Enable Advanced Security Features in User Pool.
Set policy: Block high-risk logins, challenge medium-risk with MFA.
Log in from normal device → allowed.
Simulate suspicious login (VPN, incognito browser).
Observe MFA challenge triggered.
Review CloudWatch logs → see risk events.
CloudTrail
Tracks admin changes in Cognito (create user, change pool config).
CloudWatch Metrics
Monitor failed logins, MFA challenges, blocked logins.
Cognito Advanced Security Reports
Shows risky sign-in attempts, compromised credentials.
Best Practice
Set alarms for spikes in failed logins.
Encryption
Cognito data encrypted at rest (AES-256).
Tokens signed with JSON Web Keys (RSA).
PII Handling
User data must comply with GDPR/POPIA/CCPA.
Use Lambda triggers to anonymize/cleanup deleted accounts.
Auditing
Export user pool logs to SIEM for compliance checks.
MFA can be SMS or TOTP (prefer TOTP).
Adaptive authentication protects against unusual login behavior.
Password policies + device tracking improve account security.
Tokens must have short lifetimes + be securely stored.
Monitoring with CloudTrail/CloudWatch is essential for compliance.
Enable TOTP MFA in your sandbox pool → test with multiple users.
Configure adaptive auth and test with different IPs/devices.
Write Lambda to enforce password expiry (custom policy).
Create CloudWatch alarm for 10+ failed logins in 5 minutes.
✅ End of Day 5 Content (Approx 7 hours: 3.5h theory + 3.5h labs)
Objective: Gain expertise in integrating Cognito with external identity providers (social logins, SAML, OIDC, enterprise IdPs like Azure AD/Okta) for single sign-on (SSO).
Definition: Federation allows users to authenticate with external identity providers (IdPs) instead of Cognito’s native user pool.
Types of Federation in Cognito
User Pool Federation → Social + OIDC + SAML IdPs (for app authentication).
Identity Pool Federation → External IdPs mapped to AWS IAM roles (for AWS resources).
Benefit: Users don’t need another password → login with corporate or social identity.
Supported Providers
Google, Facebook, Apple, Amazon.
Any OAuth 2.0 / OIDC-compliant provider.
Setup Steps
Create client app in Google/Facebook developer portal.
Get Client ID and Secret.
Add as IdP in Cognito User Pool.
Map attributes (e.g., Google email → Cognito email).
Best Practices
Use Authorization Code + PKCE flow.
Avoid Implicit flow (legacy).
OIDC Overview
Industry standard protocol based on OAuth 2.0.
Used for modern IdPs (Auth0, Ping, Keycloak).
Setup in Cognito
Add OIDC provider → specify Issuer URL & Client ID/Secret.
Configure scopes (openid, profile, email).
Map claims → Cognito attributes.
Example Use Case
Loyalty app integrates with corporate OIDC IdP so employees log in with work credentials.
SAML Basics
XML-based protocol widely used in enterprise SSO.
Common with Azure AD, Okta, ADFS.
Setup in Cognito
Export IdP metadata XML from enterprise IdP.
Upload metadata to Cognito.
Configure attribute mapping (NameID → username, email).
Enable in App Client.
SAML vs OIDC
SAML = enterprise legacy systems.
OIDC = modern cloud-native systems.
Why Mapping Matters
External IdPs may use different claim names (upn, emailaddress).
Cognito Mapping
Map IdP claims → Cognito attributes.
Example: emailaddress → Cognito email.
Advanced Mapping
Use Cognito pre-token generation trigger (Lambda) to transform claims.
Identity Pools Role in Federation
Map external IdPs to IAM roles.
Example:
Azure AD user → Identity Pool → IAM role → access S3.
Claim-Based Role Mapping
Assign IAM role based on IdP group/attribute.
E.g., admin=true → Admin IAM role.