My first experience using Amazon Cognito
5 min read
The entire blog post will explain to you what is Amazon Cognito, how it works, and what are all the benefits and drawbacks of this service
Building apps has become a lot easier with the advent of Serverless and one of the most common things that almost every app needs is user authentication. Serverless is all about leveraging various cloud services and integrating them within your apps instead of building them from scratch (never reinvent the wheel!).
Amazon Cognito is one of such service that can be easily integrated with both the backend (APIs) and frontend (using Amplify) of your application. This blog post talks about my very first experience with using Cognito in one of my projects.
Firstly, what is Cognito?
According to the AWS documentation:
Amazon Cognito lets you add user sign-up, sign-in, and access control to your web and mobile apps quickly and easily. Amazon Cognito scales to millions of users and supports sign-in with social identity providers, such as Apple, Facebook, Google, and Amazon, and enterprise identity providers via SAML 2.0 and OpenID Connect
In simple terms, Cognito can be used for authentication & authorization for your applications.
But, What are Authentication and Authorization?
Authentication → Authentication is the act of validating that users are who they claim to be. (Who am I?)
The most common way to authenticate
Username and Password
Authorization →Authorization is system security is a process of giving users permission to what resources they can access. (What I can uses)
Once the person is authenticated you need to provide access to the application based on their authorization level. For a user with Guest permission, only minimal privileges are provided compared to an Admin or a Premium user.
Although not the most popular auth service nor the most popular AWS service, Cognito has a few great features making it one of the go-to services for serverless applications:
Native integration with AWS services like API Gateway for easy authentication and authorization
All the user’s information will be automatically stored in the cloud. Cognito supports two kinds of attributes — standard and custom:
Standard attributes — these are the attributes that are provided by the service by default and based on your requirements, you can choose to use them and also optionally mark them as mandatory attributes. All mandatory attributes must be provided at the time of user signup. Here is the list of 17 standard attributes available. When you mark a standard attribute is Required, a user can’t register unless they provide a value for the attribute.
Custom attributes — if the default standard attributes are not sufficient for your use case, you can leverage the custom attributes. These can be of either string or numeric types and you can add a maximum of 50 custom attributes to the pool. You can specify a minimum and/or maximum length for custom attributes. However, the maximum length for any custom attribute can be no more than 2048 characters. It can be both mutable and immutable.
When you create a user, you can only write a value to an immutable attribute.
If your app client has write permission to the mutable attribute, you can change its value.
3. Confirmation emails like post user sign-up, etc will be automatically sent to the user
4. Based on your app’s requirements, you can enable phone number verification for all the users signing up and Cognito will automatically take care of sending the SMS with the OTP
5. Easy & native integration with social media identity providers like Google, Facebook, Amazon, etc.
6. Out-of-the-box security features like throttling (to prevent brute force attacks) or expiry of tokens on signouts.
Aren’t there any problems with Cognito?
There are, and the following are a few that we noticed:
Some of the configurational settings like standard attributes etc can be only set during the creation of the user pool. Editing, deleting, or manipulating these attributes post-creation can not be possible. This can be very painful at the beginning of a project when you are not sure which options you might eventually require.
Error messages provided by Cognito are not very user-friendly. Sometimes they are too technical, so the client must be capable of handling such scenarios. For example when a user tries to log in with the wrong or invalid password, etc
3. Confirmation emails, after user registration is very limited. You need to create custom HTML email templates if you want more than just a plain text email with a verification link
4. There are limitations in the number of custom field attributes, you can’t create more than 50 custom attributes in one pool
Using Cognito with API Gateway for authentication and authorization
Consider the following scenario: a client requests user information from the backend using the following endpoint — /user/:id, an API that is authorized using AWS Cognito.
Let’s take a look at how data flow for this scenario:
- Cognito returns three tokens for a successful login — token ID, access token, and refresh token
Token ID — An ID token is a piece of evidence that a user has been authenticated. It will expire every 1 hour, and a new token can be regenerated using the refresh token without asking the user to login
Access Token — Applications utilize access tokens to send queries to APIs on behalf of users. The access token denotes the consent of a certain application to access particular portions of a user’s data.
Refresh Token — this token is used to automatically fetch the latest token ID and access tokens once they are expired, without the users having to login to the application again. Refresh tokens also have an expiry time defaulted to 30 days, but can be configured in the Cognito console.
2. Pass the token ID or access token to the API as a header for the API Gateway’s Cognito authorizer to authenticate and authorize the request. API Gateway will automatically return a 401 HTTP response code if the header is not passed.
3. The Cogntio authorizer will automatically validate the token passed and only if valid, the request is forwarded to the lambda function.
4. The Lambda function will access AWS services such as RDS to retrieve the required records
5. The responses will be returned by API Gateway.
I appreciate you taking the time to read this blog post, and I hope you learned something about Amazon Cognito.
In a subsequent blog post, we’ll dive deep into Amazon Cognito!!, covering topics like creating user pools and app clients, and so on.
Thank you, Have a great day :)