The Flow: From App to S3

The "Photo Upload" Pattern

Imagine building a photo-sharing app. A naive implementation routes every photo upload through your backend server: phone → your server → S3. Your server pays the bandwidth and CPU cost for every byte of every photo. With 10,000 active users, this becomes your biggest infrastructure cost.

The correct pattern: let the phone upload directly to S3 using temporary credentials. Your server is never in the data path. This is the canonical use case for Identity Pools.

The Mechanics

Here is the exact sequence of calls that happens when a user taps "Upload Photo":

1. Login: The user authenticates with Cognito User Pool (or Google, etc.). The app receives a JWT (specifically the ID Token).
2. Exchange: The app calls the Identity Pool endpoint (GetCredentialsForIdentity or GetId + GetCredentialsForIdentity) and presents the JWT.
3. Verification: The Identity Pool validates the JWT signature against the identity provider's public keys. It resolves the user's stable Identity ID (a UUID that persists across sessions).
4. Role Assumption: The Identity Pool calls AWS STS internally: AssumeRoleWithWebIdentity, passing the JWT and the ARN of the Authenticated Role.
5. Credentials Issued: STS returns temporary credentials (Access Key, Secret Key, Session Token) to the Identity Pool, which forwards them to the app.
6. Direct Access: The app uses these credentials to call s3:PutObject directly. AWS validates the SigV4 signature, checks the IAM policy, and allows the upload.

Security properties of the temporary credentials:
- Valid for 1 hour by default (configurable from 15 minutes to 12 hours via the IAM role's trust policy).
- Scoped to exactly the permissions defined in the Authenticated Role's policy.
- If stolen, they expire automatically — no revocation infrastructure needed.
- The session token is required alongside the access key; the access key alone is useless.