Amazon Cognito

Amazon Cognito is a fully managed service that provides identity, authentication, and authorization for web and mobile applications. The core problem it solves is: how do you securely add user sign-up, sign-in, and access control to your application without building and maintaining your own user database, password hashing, multi-factor authentication, and session management? In a traditional on-premises environment, you would need to set up a directory service like Active Directory, implement a custom authentication system, or integrate with third-party identity providers. This is complex, error-prone, and requires ongoing security patching. Cognito offloads this heavy lifting to AWS.

Cognito is composed of two main components: User Pools and Identity Pools. User Pools handle authentication — they are user directories that manage sign-up, sign-in, password resets, and multi-factor authentication (MFA). Identity Pools provide temporary AWS credentials to access other AWS services like S3 or DynamoDB, based on the user's identity from a User Pool or another identity provider (e.g., Facebook, Google, SAML). Together, they allow you to implement a complete identity and access management solution for your applications.

When a user signs up for your app, Cognito User Pools stores their profile in a secure, scalable directory. You can configure the sign-up process to require email or phone verification, set password policies, and enable MFA. Behind the scenes, Cognito handles the cryptographic operations for password hashing and token generation. Upon successful authentication, Cognito returns three JSON Web Tokens (JWTs): an ID token, an access token, and a refresh token. The ID token contains user attributes (e.g., email, name). The access token is used to authorize API requests to your backend. The refresh token has a longer lifetime (default 30 days) and is used to get new ID and access tokens without requiring the user to sign in again.

Identity Pools work differently. They are not user directories; they are authorization brokers. You define one or more identity providers (e.g., a User Pool, a public provider like Facebook, or an OpenID Connect provider). When a user authenticates through one of these providers, the Identity Pool exchanges the provider's token for temporary AWS credentials (access key, secret key, session token) via the AWS Security Token Service (STS). These credentials have a configurable expiration (default 1 hour) and are scoped to an IAM role that you define. This role can grant permissions to access specific AWS resources, like read-only access to an S3 bucket. This avoids hardcoding AWS credentials in your application.

Cognito User Pools offers two tiers: Lite and Essentials. The Lite tier is free for the first 50,000 Monthly Active Users (MAUs) and includes basic features like sign-up, sign-in, and password reset. The Essentials tier (paid) adds advanced security features like adaptive authentication, compromised credentials detection, and risk-based MFA. Pricing is per MAU, with lower rates for higher volumes. For example, the first 1,000 MAUs are free, then $0.0055 per MAU for the next 50,000, and so on. Identity Pools are free for the first 100,000 authenticated users per month, and $0.0025 per authenticated user thereafter. Unauthenticated access (guests) is also free for the first 100,000, then $0.0025 per unauthenticated user.

Key configurations include: - App client settings: Each app (web, iOS, Android) needs a unique app client ID and optional client secret. - Domain: You can use a Cognito-provided domain (e.g., your-domain.auth.us-east-1.amazoncognito.com) or a custom domain for the hosted UI. - Triggers: You can invoke AWS Lambda functions during sign-up, sign-in, etc., to customize workflows (e.g., adding custom validation). - Federation: You can integrate with SAML, OIDC, and social identity providers.

On-premises, you might use Active Directory Federation Services (AD FS) or a custom authentication system with a SQL database. This requires managing server infrastructure, patching, scaling, and implementing security best practices like password hashing and session management. Cognito is fully managed, scales automatically, and integrates with other AWS services. However, it is a shared responsibility: AWS manages the service infrastructure, but you are responsible for configuring it securely — e.g., setting strong password policies, enabling MFA, and properly scoping IAM roles in Identity Pools.

Compared to third-party identity providers like Auth0 or Okta, Cognito is tightly integrated with AWS, making it easier to grant access to AWS resources. However, it may have fewer customization options for the user interface or advanced identity workflows. For the CLF-C02 exam, you should know that Cognito is the recommended service for adding authentication to your mobile or web app on AWS.

On the exam, you may see questions that ask which service to use for customer-facing user sign-up. The answer is Amazon Cognito. Another common question: how to grant a mobile app user temporary access to an S3 bucket. The answer is Cognito Identity Pools.

Scenario 1: Mobile Gaming App with User Accounts A game development company wants to allow players to create accounts, save progress, and compete on leaderboards. They use Cognito User Pools for user sign-up and sign-in, with email verification and optional MFA for high-value accounts. The game client authenticates users and receives tokens. To save game state to DynamoDB, the client uses Cognito Identity Pools to obtain temporary AWS credentials scoped to an IAM role that allows write access to a specific DynamoDB table. The role also allows read access to a leaderboard S3 bucket. This eliminates the need to embed long-term AWS credentials in the mobile app. Cost: For 100,000 MAUs, User Pools are free under the Lite tier; Identity Pools cost ~$0.25 per month. Misconfiguration: If the IAM role is too permissive (e.g., full DynamoDB access), a malicious user could delete all data. The team uses IAM policy conditions to restrict access to only the user's own records.

Scenario 2: Enterprise Web App with SAML Federation A large enterprise has an existing SAML 2.0 identity provider (e.g., Okta) for employee authentication. They are building a new internal web app on AWS and want to reuse the corporate credentials. They set up Cognito User Pools as a SAML federation provider. When an employee accesses the app, they are redirected to the corporate IdP for login. After successful authentication, Cognito creates a user profile and returns tokens. The app's backend uses the access token to authorize API calls. This avoids duplicating user directories and simplifies compliance. The team also enables adaptive authentication to detect suspicious logins. Cost: Enterprise pricing for Essentials tier applies. Misconfiguration: If the SAML metadata is not updated after IdP changes, federation breaks; the team uses AWS Secrets Manager to store metadata and automate updates.

Scenario 3: Public API with Guest Access A startup offers a public API for weather data. They want to allow unauthenticated users (guests) to access a limited tier, while registered users get higher quotas. They use Cognito Identity Pools with two IAM roles: one for unauthenticated users (guest) with read-only access to a public S3 bucket, and one for authenticated users with read access to a premium bucket and write access to a support ticket table. Unauthenticated users call GetId without a token and receive credentials scoped to the guest role. Authenticated users use a User Pool token. This scales automatically. Cost: The first 100,000 unauthenticated users per month are free. Misconfiguration: If the guest role has write permissions, malicious users could upload malware. The team restricts guest role to read-only and uses AWS WAF to block common attacks.