When building an app, you inevitably face two questions: how do I verify who this person is, and what should this person be allowed to access? Amazon Cognito and IAM are the AWS services that solve exactly these problems.
DVA-C02 exam questions in this area focus on who can call this API and how to authenticate users.
What is Amazon Cognito?
Think of Cognito as your app's membership management system plus access pass desk. Instead of building your own login server, AWS handles user registration, login, and authentication for you.
Cognito is divided into two main components.
Cognito User Pools — Who are you? (Authentication)
This component verifies a user's identity when they log into your app — like a security guard checking employee badges at a building entrance.
When a user successfully logs in, Cognito User Pools issues a JWT token — a digital certificate that says this person is an authenticated user.
Features supported by User Pools: Social logins (Google, Facebook, Apple) Enterprise identity federation (SAML/OIDC) Multi-factor authentication (MFA), password policies Email/SMS verification codes AWS-hosted UI (a ready-made login page)
Cognito Identity Pools — What can you do? (Authorization)
This component distributes AWS access keys to users who have already been authenticated. For example, it can issue temporary AWS credentials so that a mobile app user can upload files directly to their own S3 bucket.
If User Pools is checking the badge, Identity Pools is issuing floor-access cards for each part of the building.
Different permissions can be granted to authenticated users and unauthenticated guest users Present the JWT token from User Pools to Identity Pools to exchange it for temporary AWS credentials
Typical flow: User logs into User Pool → receives JWT token → exchanges token at Identity Pool for AWS credentials → directly accesses AWS resources like S3 and DynamoDB
!Cognito User Pools versus Identity Pools
API Gateway Authorizers
API Gateway is the front door of your application. Whenever someone calls an API, it needs to verify that they actually have permission to do so. This verification role is performed by an Authorizer.
| Type | Description | When to use | |------|-------------|-------------| | Cognito Authorizer | Validates JWT tokens from Cognito User Pools. No custom code required. | When app users are calling your API | | Lambda Authorizer | Custom auth logic implemented as a Lambda function. | When using special token formats or third-party auth systems | | IAM Authorizer | Requests are signed using AWS Signature V4. | When AWS services call each other internally |
Regular app user authentication → Cognito Authorizer Legacy systems or custom authentication → Lambda Authorizer Service-to-service AWS calls → IAM Authorizer
STS (Security Token Service)
STS issues temporary AWS credentials — like a visitor pass valid for today only. Instead of permanent passwords, it uses short-lived temporary keys, which is much more secure.
AssumeRole: Temporarily borrow a role in another AWS account to access that account's resources AssumeRoleWithWebIdentity: Exchange a web login token (e.g., from Google) for AWS credentials GetSessionToken: Issue a temporary token after MFA authentication
Exam Key Points
"Mobile/web app user registration/login" -- Cognito User Pool
"Issue AWS credentials to authenticated users" -- Cognito Identity Pool
"Validate JWT token at API Gateway" -- Cognito Authorizer
"Custom authentication logic" -- Lambda Authorizer
"Service-to-service AWS call authentication" -- IAM Authorizer (Sig V4)
"Assume a role in another account" -- STS AssumeRole
User Pool = Authentication (who you are), Identity Pool = Authorization (what you can do)