Understanding AWS Cognito and IAM Roles
User pools, Identity pools, and IAM roles to share access to AWS resources. A comprehensive walkthrough with common use cases and code samples.
What and How
User pool stands for the database where users are held. The users’ data can either be drawn from the external identity providers (Google, Facebook, etc) or the Cognito way, i.e. email, username, password, etc. One of the basic steps in setting up a user pool is to give it a domain name and attaching identity providers. For the user pool, there can be one or more App clients which bind the identity provides. Multiple app clients are very useful when you have several platforms calling you API like mobile, websites, etc with different auth flows (out of scope stuff in this post). Once configured, should look like below.
Usage of user pools
One of the main reasons to have a user-pool is to authenticate users and authorize them for an API gateway. The users will be of the following nature.
As you can see every user carries the
sub attribute which corresponds to their unique identity. This is available in the
idToken issued by the user-pool after successful authentication. The
jwtToken created from the
idToken can be used to access secured endpoints in the API gateway. For simple web authentication scenarios read here.
Accessing the API is straightforward with the
Authorization TOKEN Header in requests.
Now imagine you have a web page which enables image uploads (a very simple but sensible use case). Uploading them via REST API calls will not make sense as Lambdas are charged based on CPU hours. The best option is to upload them to a temporary space (which cleans itself) in a S3 bucket and send the image key to the REST API (which then can be organized afterwards).
Let’s give access to S3 from the browser, put the secret key and configure aws-sdk? LOL NO!
You don’t want to expose any access keys to the users. Or you don’t want users (unauthenticated) to fill your S3 buckets.
Making Sense out of Identity Pools
What and How?
Identity pools is a way of granting AWS services access to your users. This is a conservative way of having a single authorization mechanism to AWS resources. Let’s create one from the AWS console. Once done it should like below (It is demonstrated as Federated Identities in AWS).
As you can see, there are two associated IAM roles as Unauthenticated and Authenticated. As it literally means, we may grant access to guest users as well as signed up users.
Usage of Identity Pools
Although we have set-up the identity pool it must be noted that we must provide identity pool id to our web app in order to interact with other services like S3. Now the users signed in will have the access to resources that Identity pool has and vice versa.
The access of resources like S3 from the browser will require you to enable CORS within S3. I will not discuss as it is beyond the scope. Read here.
IAM Roles or Identity and Access Management Roles, defines the level of access to AWS resources a service assuming a particular IAM Role has. For example for authenticated web site users’ level of authorization will be declared by the Cognito_vinylidpAuth_Role carries as per my image from Identity Pool Edit Page. So in our simple case, we need write access to the S3 bucket. So in the IAM console, we can simply select the role and grant that access.
Once I have added the above system the authenticated web site users will be able to upload their pictures to S3 followed by the REST API call they can move the images to a proper folder in the bucket (or whatever they intend to do with the images). If we are to access S3 after REST API within a Lambda function we must give the same access to the Lambda Function Role.
I hope this might make things a little clear amidst the complicated documentation at AWS. Happy Reading!