Cognito Security

Amazon Cognito handles customer identity for applications. It has two main components:

User Pools (Authentication)

• Managed user directory with sign-up, sign-in, and account recovery
• Issues JWT tokens (ID token, access token, refresh token)
• Built-in MFA (SMS, TOTP, email)
• Threat protection (formerly called advanced security features): compromised credential detection, adaptive authentication, IP allow and deny lists
• Social and enterprise federation (Google, Facebook, Apple, SAML, OIDC)

Identity Pools (Authorization)

• Exchange tokens for temporary AWS credentials via STS
• Map authenticated and unauthenticated users to IAM roles
• Fine-grained access to AWS resources per user

Security Best Practices

• Enable threat protection for risk-based adaptive authentication and compromised-credentials checks
• Configure strong password policies (length, complexity)
• Use custom authentication flows (Lambda triggers) for additional validation
• Implement token revocation for compromised sessions

How It Goes Wrong in Practice

The textbook Cognito incident is credential stuffing against a user pool that runs plain username-password authentication with MFA off and threat protection never enabled. Users reuse passwords across sites, breach dumps circulate, and an attacker replaying leaked credential pairs against your sign-in endpoint will land a percentage of them; this is exactly the attack Cognito's compromised-credentials detection exists to catch, since it compares your users' credentials against known leaked credential lists and commonly guessed passwords. Teams that do enable threat protection still trip over its documented boundaries: compromised-credentials detection works on username-and-password flows but has no access to passwords in SRP sign-in, threat protection does not apply to federated sign-in at all, it applies no rate limits (volumetric abuse is AWS WAF's job), and it does not monitor machine-to-machine client-credentials traffic. Each of those is a gap someone assumed was covered. On the identity pool side, the classic misconfiguration is the over-privileged guest: unauthenticated identities are mapped to an IAM role that was scoped generously during development, meaning anyone on the internet can mint temporary AWS credentials and use whatever that role allows, no password required. Review the unauthenticated role as if it were a public API, because it is one. Finally, watch the authentication flows enabled on each app client: leaving USER_PASSWORD_AUTH enabled when your app only uses SRP hands attackers a simpler oracle for password guessing.

Practical Check: Review Pool Security Settings

Dump the pool configuration and read it critically:

aws cognito-idp describe-user-pool --user-pool-id eu-west-1_EXAMPLE

Check MfaConfiguration (OFF, ON, or OPTIONAL; note that adaptive authentication's risk-based MFA requires MFA to be set to optional so it can escalate selectively), the password policy block, deletion protection, and the account recovery settings. Then in the console, open the user pool's Threat protection menu and confirm the enforcement mode: audit-only gathers risk metrics without acting, and AWS recommends running audit-only for two weeks or more before switching to full-function mode so you can tune against false positives.

Frequently Asked Questions

What happened to "advanced security features"?
They were renamed threat protection and are available in the Plus feature plan. The capabilities are compromised-credentials detection, adaptive authentication with risk scoring, IP address allow and block lists, and log export of threat assessments to S3, CloudWatch Logs, or Data Firehose.

Does threat protection cover all sign-in paths?
No. It supports username-password flows fully and adaptive authentication for SRP, but compromised-credentials checks cannot see SRP passwords, custom authentication has its own separate enforcement configuration, and federated sign-in through external identity providers is not covered. Map your actual authentication flows against these boundaries before assuming protection.

What should the automated responses be?
Cognito lets you assign responses per risk level: allow, optional MFA, require MFA, or block, with optional user notification emails. A common progression is notify on low risk, require MFA on medium, block on high. You can set these globally per user pool and override them per app client, and you cannot assign a weaker response to a higher risk level.

Are user pools and identity pools interchangeable?
No, and the distinction is security-critical. User pools authenticate people and issue JWTs your application verifies. Identity pools exchange tokens (or nothing, for guest access) for temporary AWS credentials via STS. A weakness in user pool configuration exposes your application; a weakness in identity pool role mapping exposes your AWS account. Audit the two with different checklists, because the failure modes and the blast radii are entirely different.