Customer authentication
Adding sign-in, federation and API authorization to an existing customer-facing app with Cognito user pools, identity pools, ALB and API Gateway authorizers.
Exam tasks: 3.2 (determine a strategy to improve security: authentication and authorization for applications)
The decision: does the app need to know who the user is (a user pool issuing tokens), or does the user's device need AWS credentials to call AWS services directly (an identity pool)? Then: where do you check the token (ALB, API Gateway or the app)?
This page is about customers and app users. For employees signing in to AWS, see federation.
User pool or identity pool?
| User pool | Identity pool | |
|---|---|---|
| What it is | A user directory and OIDC identity provider | A broker that swaps an identity token for temporary AWS credentials |
| Output | ID, access and refresh tokens (JWTs) | STS credentials for an IAM role |
| Sign-in sources | Its own users, plus social (Google, Apple, Facebook, Amazon), SAML and OIDC providers | User pools, social providers, SAML, OIDC, your own auth (developer authenticated), or none (guest) |
| Used to call | Your APIs, through ALB or API Gateway | AWS services directly: S3, DynamoDB, IoT, Kinesis |
| Authorization | Groups and custom claims in tokens | IAM roles, rule-based role mapping, principal tags for ABAC |
Credentials in a mobile app
"A mobile app uploads photos straight to S3 without embedding keys" points to an identity pool that hands out
a role scoped to the user's own prefix, for example with the cognito-identity.amazonaws.com:sub policy variable.
User pools
- Sign-up and sign-in, email and phone verification, password policies, MFA (SMS, TOTP), and passwordless options (passkeys, one-time codes) on the Essentials and Plus feature plans.
- Managed login is the ready-made sign-in UI on a Cognito or custom domain. It handles OAuth 2.0 flows and the redirects to social, SAML and OIDC providers, so you don't build those screens.
- Federation for business customers: add each customer's SAML or OIDC IdP to the user pool. Users are matched to the right IdP by email domain, and the app still receives one kind of token.
- Lambda triggers customize flows: pre sign-up checks, custom claims (pre token generation), and user migration, which moves users from an old user store the first time they sign in.
- Threat protection (Plus plan) detects compromised credentials and risky sign-ins and can require MFA or block.
Legacy: use Managed login instead
The older hosted UI is still available as the "classic" hosted UI. New user pools use managed login, which supports branding without custom CSS.
Migrating an existing user base
"Move users from the legacy database without forcing a password reset" points to the user migration Lambda trigger. A bulk CSV import can't bring passwords, so imported users must reset them.
Checking tokens at the front door
| Front door | Options | What to know |
|---|---|---|
| ALB | authenticate-cognito or authenticate-oidc listener rule action | HTTPS listeners only. ALB runs the login redirect and passes user claims to targets in headers. Good for adding login to an existing web app with no code change |
| API Gateway REST API | Cognito user pool authorizer, Lambda authorizer (token or request), IAM (SigV4) | Cognito authorizer validates the JWT with no code. Lambda authorizer handles custom tokens or third-party IdPs, with caching |
| API Gateway HTTP API | JWT authorizer, Lambda authorizer, IAM | JWT authorizer works with any OIDC issuer, including Cognito |
| App code | Verify JWT signature against the user pool's JWKS | Most flexible, most work |
API keys are not authentication
API Gateway API keys identify a client for usage plans and throttling. They aren't a secure way to authorize users. Use Cognito, Lambda or IAM authorizers for that.
IAM auth for public users
IAM (SigV4) authorization means the caller signs with AWS credentials. For end users that only works if an identity pool gives them credentials first. For a plain web or mobile app talking to your API, a Cognito authorizer is simpler.
Fine-grained authorization
Tokens say who the user is. Deciding "can this user edit booking 4471?" is a separate step.
- Amazon Verified Permissions stores policies written in Cedar and evaluates them per request. It can use a Cognito user pool as its identity source and can protect API Gateway APIs through a generated Lambda authorizer.
- Pick it when authorization logic is scattered across services and the team wants one place to change and audit rules.
Scenarios
A user pool federates with each partner's SAML IdP, and the ALB authenticate action runs the sign-in flow before requests reach the app, so the code doesn't change. An identity pool issues AWS credentials, which the app doesn't need. API keys don't authenticate users, and IAM Identity Center is for workforce access to AWS accounts and apps, not an external user base for a custom app.
The user pool handles social sign-in and issues tokens. The identity pool turns those tokens into short-lived credentials, and the policy variable for the identity ID limits each user to their own prefix. IAM users with keys on devices, embedded API keys and public writes all break the security requirements.
The migration trigger checks the password against the legacy store and creates the user in Cognito with that password, so users migrate silently as they sign in. A CSV import can't bring password hashes, so every customer would need to reset. A pre token generation trigger only changes token claims, and an identity pool doesn't give you a user directory.
Further reading
Secrets and least privilege
Removing hardcoded credentials, choosing Secrets Manager or Parameter Store, and trimming IAM permissions in an existing system with Access Analyzer, boundaries and Roles Anywhere.
Backup automation
Replacing ad hoc snapshots in an existing estate with AWS Backup plans, org-wide backup policies, cross-account copies, Vault Lock, restore testing and Data Lifecycle Manager.