An Amazon Cognito service that exchanges a trusted identity proof for AWS temporary credentials. It sits between the application and AWS STS, allowing authenticated users or federated identities to obtain scoped access without embedding long-lived AWS keys in the app.
How Cognito Identity Pools Work
A Cognito Identity Pool is a federation and credential-exchange layer. It accepts trusted user identities from an identity provider, then calls AWS STS so the application can receive temporary, scoped AWS credentials instead of embedding static access keys.
This design matters because it separates authentication from AWS authorization. The pool does not invent a new user store; it brokers trust from a login event into short-lived AWS permissions that the app can use against AWS services.
Where It Fits in an AWS Access Flow
Identity Pools sit between the application, the upstream identity proof, and the AWS permissions boundary. They are commonly used when a web or mobile app needs to let signed-in users access AWS resources such as S3, DynamoDB, or API-backed services without hard-coding long-lived AWS credentials in the client.
The key architectural idea is scoped temporary access. The application can ask for AWS credentials only after a successful trust decision, and those credentials can be limited by role mapping, audience, or authentication state. That keeps the access path narrower than a shared key or generic administrator credential.
Cognito Identity Pools are often confused with user-directory features, but they solve a different problem. User Pools manage sign-up and sign-in, while Identity Pools translate a trusted identity into AWS access. The second step is what makes the service relevant to cloud authorization and temporary credential issuance.
Common Trust and Credential Patterns
Identity Pools can work with social logins, enterprise federation, and authenticated or unauthenticated guests, depending on how the pool is configured. In each case, the material security question is the same: what identity proof is trusted, and what AWS privileges should that proof unlock?
That makes role mapping, token trust, and session scope the central design choices. If the trusted assertion is too broad, the resulting AWS session can reach more services than intended. If it is too weak, the application may grant access without a reliable identity basis.
For a deeper view of the surrounding workload-identity pattern, the Cloud Workload Identity Guide explains how AWS STS fits into broader keyless access designs. For the identity lifecycle side of the same problem, the NHI Lifecycle Management Guide covers provisioning, rotation, and offboarding, which are the controls that keep temporary access from turning into long-lived sprawl.
Why the Pattern Matters for Security
The main security benefit is that the app can avoid embedding reusable AWS keys. Temporary credentials reduce blast radius, support least privilege, and make revocation and expiration more practical than with static secrets.
The trade-off is that the trust chain must be configured correctly. If the upstream identity provider, token validation, or role mapping is weak, the application can still end up with excessive access, confused-deputy style privilege drift, or an overly permissive guest path. In other words, the risk shifts from key storage to trust and authorization design.
For the broader issue of overexposure and lifecycle drift in non-human access paths, the Top 10 NHI Issues is a useful companion reference. The same pattern appears whenever temporary credentials are issued without clear ownership, tight scope, or consistent review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Identity Pools depend on issuing and controlling temporary authentication material. |
| IA-9 — Service Identification and Authentication | Federated workloads and apps use this pattern to authenticate to AWS services. | |
| AC-6 — Least Privilege | Identity Pools should scope the AWS permissions granted by temporary credentials. | |
| Recommendation — Use IA-5 to manage token and credential lifecycle for pooled AWS access. Apply IA-9 when non-human or federated identities obtain AWS session credentials. Limit role mappings so temporary AWS sessions receive only required privileges. | ||
