Free — no signup required

User Pool Configuration: The Key Settings

2 min read

What You Actually Configure

A Cognito User Pool is not just a database — it's a configurable authentication policy engine. Understanding the key settings is essential for both building and troubleshooting.

Sign-in Identifiers
You choose what users sign in with: username, email address, phone number, or any combination. This choice is permanent — you cannot change it after the pool is created without migrating users to a new pool.

Password Policy
Define minimum length, required character classes (uppercase, lowercase, numbers, symbols), and temporary password expiration. Cognito enforces these at sign-up and password change time.

Multi-Factor Authentication (MFA)
Three modes:
- Off: No MFA.
- Optional: Users can enroll in MFA but aren't required to.
- Required: Every user must complete MFA on every sign-in.

MFA methods: SMS (requires an SNS-linked phone number) or TOTP (Time-based One-Time Password via Google Authenticator, Authy, etc.). TOTP is preferred — it doesn't depend on SMS delivery reliability and is resistant to SIM-swapping attacks.

User Attributes
Standard attributes (email, phone_number, name, birthdate, etc.) follow the OIDC standard. You can also define custom attributes (e.g., custom:tenant_id, custom:subscription_tier). Custom attributes are immutable by default — users cannot change them, only admins can. This makes them useful for storing trusted metadata.

App Clients
Each application that integrates with your User Pool gets its own App Client — a client ID and optional client secret. The App Client defines which OAuth flows are allowed, which scopes are exposed, which identity providers are enabled, and the allowed redirect URIs. A single User Pool can have multiple App Clients (e.g., one for your web app, one for your mobile app, one for your internal admin tool).

Token Expiration
Configurable per App Client:
- Access Token: 5 minutes to 1 day
- ID Token: 5 minutes to 1 day
- Refresh Token: 60 minutes to 10 years

Shorter-lived tokens reduce the window of exposure if a token is stolen. Longer-lived refresh tokens improve user experience (fewer re-logins). The right balance depends on your threat model.

Interview Tip

A common interview question: "A user's account is compromised. How do you immediately revoke their access in Cognito?" The answer has two parts: (1) Disable the user in the User Pool — this prevents new sign-ins immediately. (2) Revoke the Refresh Token using the RevokeToken API or GlobalSignOut — this invalidates all existing sessions. However, existing Access Tokens remain valid until they expire (up to 1 hour by default). This is a fundamental limitation of stateless JWTs. If you need sub-minute revocation, you must implement a token blocklist (e.g., check a DynamoDB table in your Lambda authorizer on every request).

This is one of 18 chapters

Get every chapter — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

See pricing