Amazon Cognito Security Guide: User Pools, Identity Pools, Guest Access and Token Handling

Amazon Cognito sits on the public internet and issues both application tokens and real AWS credentials, so a writable attribute, a generous guest role or a token that is never revoked can give anonymous users access to your AWS account. This guide covers the two halves of Cognito: user pools, which authenticate customers and issue JWTs, and identity pools, which exchange those tokens (or nothing at all, for guests) for temporary AWS credentials. It sets out the configuration choices that matter for security, how to verify and revoke tokens, how to log and detect abuse, and the misconfigurations that recur in assessments. It is for application security engineers, cloud architects and teams building customer sign-in on AWS. For customer identity strategy in general, see the Customer IAM (CIAM) Guide; feature behaviour here was checked against the Amazon Cognito Developer Guide on 27 October 2026.

Key takeaways

• Identity pools hand out AWS credentials: an unauthenticated role is AWS access for anyone who knows the identity pool ID, which is usually embedded in the client app.
• Trust policies must check aud and amr: IAM now requires the identity pool ID condition, but older roles and missing amr checks remain common.
• App clients can write every attribute by default: any attribute used for authorisation must be removed from WriteAttributes on every app client.
• Verify tokens properly: check signature, iss, token_use, aud or client_id and exp, and remember that offline verification cannot see revocation.
• Turn on the defences that are off by default: refresh token rotation, threat protection in audit mode first, identity pool data event logging and user existence error suppression on API-created clients.

How identity and access work in Amazon Cognito

Tokens

The ID token carries user attributes and has an aud equal to the app client ID. The access token carries scopes, cognito:groups and client_id. The refresh token is encrypted and opaque. ID and access tokens default to one hour and can be set between 5 minutes and 1 day; refresh tokens default to 30 days and can be set from 60 minutes to 10 years. Tokens can contain personal data and details of your authorisation model, so protect them in transit and at rest. For general token hygiene see the Token and Session Security Guide.

Verifying user pool JWTs

1. Confirm the token is a three-part JWT and that alg is RS256.
2. Match kid against the keys at https://cognito-idp.<Region>.amazonaws.com/<userPoolId>/.well-known/jwks.json, cached by kid and refreshed when an unknown kid arrives with the correct issuer.
3. Check exp locally.
4. Check aud (ID token) or client_id (access token) equals your app client ID.
5. Check iss equals https://cognito-idp.<Region>.amazonaws.com/<userPoolId>.
6. Check token_use is access for APIs that accept access tokens only, or id where you deliberately accept ID tokens.

AWS recommends the aws-jwt-verify library for Node.js, or any reputable OpenID Foundation listed library elsewhere. APIs should authorise on access tokens and scopes rather than ID tokens. See the JWT Security Guide.

Identity pools: authenticated and guest identities

Every identity pool identity is authenticated or unauthenticated, and each type maps to an IAM role. Guest access gives users who never signed in a unique identity ID and AWS credentials. The identity pool ID needed to request them ships inside the web or mobile app, so treat the unauthenticated role as public. The trust policy for both roles uses "Federated": "cognito-identity.amazonaws.com" and sts:AssumeRoleWithWebIdentity, with conditions on cognito-identity.amazonaws.com:aud (the identity pool ID) and cognito-identity.amazonaws.com:amr (authenticated or unauthenticated). For how these sessions behave, see the AWS STS and AssumeRole Guide.

Do not use aws:SourceIp conditions in roles assumed through the enhanced flow, because Cognito makes the STS request, so the source IP never matches the user.

Admin roles and privileged access

Cognito administration is privileged access to your customers' accounts. The administrative APIs can create users, set passwords, mark email addresses as verified and sign users out.

• Separate administration from the app: the application's runtime role should not hold cognito-idp:Admin* actions unless it genuinely needs them, and never cognito-idp:AdminSetUserPassword, AdminUpdateUserAttributes or UpdateUserPoolClient on the production pool from a public-facing service.
• Treat email_verified as sensitive: an administrator can set it to true with AdminUpdateUserAttributes. Verified email and phone aliases transfer between accounts: if a user verifies an address that is already a verified alias on another account, Cognito moves the alias and marks it unverified on the original account. Test account recovery and linking flows against this behaviour.
• Protect pool configuration: changes to app client flows, callback URLs, identity providers, Lambda triggers and identity pool roles should go through infrastructure as code with review. A changed callback URL or added IdP is an account takeover path.
• Guard Lambda triggers: pre sign-up, pre token generation and migration triggers run with their own roles and can alter claims. Whoever can edit trigger code controls the tokens.
• Scope the identity pool roles: the authenticated role is effectively granted to every customer. Use ${cognito-identity.amazonaws.com:sub} policy variables or principal tags so each user can only reach their own S3 prefix or DynamoDB items.

Integrations, API tokens and service accounts

Attribute permissions

A new app client can read and write all standard and custom attributes. If WriteAttributes is not set, users can change any attribute for themselves with UpdateUserAttributes. Because attributes are shared across every app client in the pool, a value written through one client appears in tokens issued by all of them. AWS's guidance is direct: if your application or identity pool makes authorisation decisions on an attribute (for example custom:role or custom:tenant_id), remove it from the WriteAttributes of every app client. Custom attributes cannot be deleted or changed after creation, so plan the schema before production. The legacy dev: developer attributes have been replaced by app client permissions.

Role selection and principal tags

Identity pools can choose a role per provider with up to 25 rules on token claims, or honour a preferred_role from user pool group membership. If no rule matches, role resolution either denies credentials or falls back to the authenticated role; choose deny. Attributes for access control map claims to principal tags (by default sub and aud) that IAM policies can test. Rules and tags are only as trustworthy as the claims behind them, which is why attribute write permissions matter.

Machine-to-machine clients

App clients with a client secret can use the OAuth client credentials grant against custom scopes defined on a resource server. These are non-human identities: store the client secret in a secrets manager, give each calling service its own app client, keep scopes narrow and rotate the secret on a schedule. Threat protection does not apply to client credentials requests, so monitor them separately. See the OAuth 2.0 Security Best Current Practice Guide.

Federation to external IdPs

User pools can federate to SAML and OIDC providers. Map IdP attributes carefully: a mapping into an attribute used for authorisation hands that decision to the IdP's administrators. Threat protection cannot be used with federated sign-in, so rely on the IdP's own controls. See the Customer IAM (CIAM) Guide.

Logging and detection

Cognito masks passwords and tokens in CloudTrail as HIDDEN_DUE_TO_SECURITY_REASONS but does not mask personal data placed in other request fields. Relevant ATT&CK techniques are T1110.004 Brute Force: Credential Stuffing, T1078.004 Valid Accounts: Cloud Accounts for misuse of issued credentials, and T1580 Cloud Infrastructure Discovery for guests probing the account.

Metrics

• Guest role permissions: number of actions allowed to the unauthenticated role; target zero if guests are not needed.
• Authorisation attributes writable by any app client: target zero.
• App clients with refresh token rotation and revocation enabled: target 100 percent.
• Credential stuffing signal: failed sign-ins per hour and per source IP against a baseline.
• Threat protection coverage: share of password-based sign-ins assessed in full function mode.

Hardening baseline

Rollout

1. Inventory user pools, app clients, identity pools and their roles; export each client's attribute permissions, flows and token settings.
2. Close public AWS access first: review unauthenticated roles, switch any basic flow pools to enhanced flow where possible, add amr conditions, and set role resolution to deny.
3. Lock attributes: set explicit WriteAttributes on every client in a test pool, run the app's sign-up and profile flows, then promote.
4. Tokens: enable revocation on older clients, then rotation; move integrations from REFRESH_TOKEN_AUTH to GetTokensFromRefreshToken, which rotation requires.
5. Threat protection: enable audit only, review risk decisions for at least two weeks, then switch to full function per app client. Rollback is returning the client to audit only.
6. Logging: enable identity pool data events on the organisation trail and build the failed sign-in and ForgotPassword queries into alerts.

Small versus large deployments: a single app can run one user pool with a few clients and no identity pool. Multi-tenant platforms should decide early whether tenants share a pool (tenant attribute, read-only, enforced in every API) or get separate pools, because attributes are shared across all clients in a pool and custom attributes cannot be changed later.

Common misconfigurations

• Guest roles with real permissions: an unauthenticated role allowed to read a bucket or invoke a function is open to anyone with the pool ID from the app bundle. In basic flow there is not even a scope-down policy.
• Self-writable authorisation attributes: users call UpdateUserAttributes to set custom:role to admin, and the next ID token carries it to every API that trusts it.
• Trusting ID tokens or skipping token_use: an ID token minted for one app client is accepted as an API access token by another.
• Assuming sign-out kills tokens everywhere: revoked tokens still pass offline JWT checks until exp, and managed login cookies survive GlobalSignOut unless users are sent to the Logout endpoint.
• Username enumeration through API-created clients left on LEGACY, feeding credential stuffing of the kind that reached about 18,000 accounts and data on roughly 7 million people in the 23andMe breach.
• Relying on threat protection for volume attacks: it applies no rate limits; put AWS WAF in front of the user pool.

Framework mapping

Practitioner checklist

• Disable guest access unless documented; scope any unauthenticated role to the minimum.
• Confirm every identity pool role trust policy checks aud and amr.
• Keep identity pools on the enhanced flow and set role resolution to deny.
• Set explicit WriteAttributes on every app client and exclude authorisation attributes.
• Verify JWTs fully, including token_use and client_id, and authorise APIs on access tokens.
• Enable token revocation and refresh token rotation on every client.
• Set PreventUserExistenceErrors to ENABLED on every client.
• Run threat protection in audit only, then full function, and add AWS WAF rate limits.
• Log identity pool data events and alert on failed sign-in and password reset bursts.

Standards and references

• AWS: Amazon Cognito identity pools IAM role trust and permissions
• AWS: Working with user attributes
• AWS: Verifying JSON web tokens
• AWS: Ending user sessions with token revocation
• AWS: Refresh tokens
• AWS: Advanced security with threat protection
• AWS: Logging Amazon Cognito API calls with AWS CloudTrail
• OWASP: Application Security Verification Standard 5.0

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · AWS STS and AssumeRole Guide · Token and Session Security Guide · Account Takeover Prevention Guide · AWS Security Guide