Getting started with AWS Cognito Identity Pool
Estimated time to read: 5 minutes
This is an old article that I wrote in 2019 and I am migrating it from there. The core concept and the flow of AWS Cognito Identity pool are still the same but you should use latest AWS SDK(v3 in 2026).
Prerequisites
- AWS Account
- Basic knowledge of AWS IAM
- Basic knowledge of AWS Lambda and API Gateway
- A little bit of coding
Terminologies to be Familiar With
-
Identity — An Identity is something by which you recognize your user throughout the scope of your application. It can be a user's username, email, mobile number or a UUID you assign to them.
-
Cognito Identity Pool — An identity pool stores your identities and all the information required to authorize a user. All the identities share the privilege that is assigned to the Identity pool.
-
Developer Authenticated Identity — There are some Identity providers like Google, Facebook, etc which a developer can trust. They act as login providers for the application but if the developer doesn't want to rely on any of them and implement his/her own authentication then the developer will become the login provider and the Identities created under his/her authentication will be called Developer Authenticated Identities.
Introduction
Before diving into Cognito Identity Pool, let me explain the problem it solves. Once, I received a task to create AWS IAM Authenticated APIs. Initially, this seemed straightforward: go to your API Dashboard, select resource and turn on IAM Authorization.
However, if you want your users to access this API and use your AWS resources client-side, you'll need AWS Credentials — a pair of keys (Access Key and Secret key). You cannot simply generate keys from the console and share them with clients, as this would allow the user to use the key outside of the client application.
Keys must be invalidated and regenerated periodically to ensure they're not misused. These are called temporary credentials. Fortunately, AWS provides services to manage this automatically, and Cognito is one of them.
How I Resolved It
I created a Cognito Identity Pool to create Developer Authenticated Identities and generated IAM credentials for these Identities. I selected Developer Authenticated Identities because my application already had its own authentication process.
The path to completion wasn't straightforward — AWS documentation was extensive and confusing. After many hours of research, I discovered the correct flow to follow.
Goals
- Create a Cognito Identity Pool
- Give required permissions to Identities in this pool
- Create an Identity
- Add IAM Authenticated API using API Gateway, create AWS Lambda function, and integrate them
- Generate temporary credentials for an Identity and use it to call the API
Steps to Use Cognito Identity Pool
Create a Cognito Identity Pool with Developer Authenticated Identities
Step 1: Create an Identity pool in AWS Cognito. Fill in the name. Choose Authentication providers → custom and enter a Developer provider name (such as test.login) which is immutable. Click "Create Pool."
Add Permission for Identity
Step 2: AWS will request that you create two Roles for your Identity pool — one for Authenticated Identities and one for Unauthenticated Identities. You cannot choose pre-existing roles; you must create new ones.
Edit the policy document and add relevant permissions to use AWS services. We're adding "execute-api:Invoke" because we're going to call an IAM authenticated API. You can edit or add policies for roles later.
After completion, you'll see a page confirming successful Identity Pool creation.
Note your Identity Pool Id for later use. Select your platform to view its relevant APIs.
Create an Identity
Step 3: Use getOpenIdTokenForDeveloperIdentity() to get an Identity Id and Token. It creates an Identity if it doesn't exist. You'll need AWS credentials to call this API, so execute it from your application backend.
If everything is correct, you'll receive:
Access Identity browser from the Identity Pool Dashboard and select this Identity.
Get Credentials for the Identity
Step 4: With the user's Identity Id and temporary token, exchange them for temporary AWS Credentials. AWS STS provides these, but AWS Cognito handles this automatically behind the scenes.
Call getCredentialsForIdentity() API to get temporary credentials. You don't need your AWS Credentials to call this API. For instance, if building an Android App, you can give the IdentityId and Token to the frontend and call this API.
Response:
{
AccessKeyId: [AccessKeyId],
SecretKey: [SecretKey],
SessionToken: [Session Token],
Expiration: 2018-09-21T11:59:15.000Z
}
Users can now access your AWS resources using these temporary credentials.
Testing
Step 5: Create a Lambda function that returns a simple response like "Hello user."
Step 6: Create an API and a method within it. Integrate the method with the Lambda function. Go to "Method Request" and enable "AWS_IAM" authorization. This ensures only permitted AWS Credentials associated with your account can access this method.
Enable CORS and deploy your API.
Step 7: To call an API, you must insert AWS SigV4 (AWS Signature version 4) in your request header. Various methods exist for generating the signature. We'll use the AWS4 node module.
Open terminal and run:
Also install the 'request' node module for HTTP requests:
Use these to generate a signature from temporary credentials and make an HTTP request.
In the end
If the user receives the response from Lambda, everything has worked correctly. You can either implement all coding server-side and give temporary credentials to the client, or implement it in a Lambda function, integrate it with an unauthenticated API, and have your client call this API to obtain temporary credentials.
Later.