AWS Cognito as a backendless user management

Cloud Computing Reading Time: 6 min.

  • views7808
  • 0comments

In the second quarter of 2016, the AWS team realized a new functionality with AWS Cognito service called “User Pools.” The functionality is a solution to user management for your application without the need to create a backend to handle it. In the standard scope, a register mechanism, sign-in, sign-out, password reset, send verification code, and capability are implemented to run custom scripts during the registration or sign-in process. A typical implementation of these elements–seemingly trivial functionalities–consumes time and additional server resources during an application development on both  web and mobile platforms. However, AWS Cognito gives us a ready-made user-management backend without having to worry about scalability, reliability, and security factors. Therefore, it is worth it to get to know the solution better. Let’s see what the User Pools offer us.

User Management

The User Pools provide a simple graphical interface where you can manage your users for both web and mobile applications.


They are capabilities such as the following:

  • lookup users–a simple search field,
  • a manual user confirmation–if you disable an automatic user confirmation mechanism, or a user did not input a verification code after the registration process, you can confirm the account manually.
  • enable or disable the user—an easy way to invoke or revoke access to your application,
  • enable or disable multi-factor authentication—MFA increases security by requiring an additional factor beyond a username and password to sign into an app, and
  • reset the user’s password.


Attributes are used in a user registration form. The User Pools give us 16 standard fields such as name, email, address, birth date, etc. When these attributes are not enough, you can add 25 additional fields. Take into account that there is length limit for each attribute: a maximum 256 characters.


You can define which attributes are required during a registration process. When a user omits the required filed, the AWS Cognito will return an appropriate error message. When it comes to the Alias column, which we have seen in the above picture, we can decide by which attributes the user can sign in to your application. There are three such attributes: email, phone, and preferred username. The preferred username field is quite useful because you can put in any custom ID. One of the most important things is that after creating the User Pool, all attributes marked as required or as an alias cannot be changed. It is quite uncomfortable. You can imagine that, after a few months, your needs to user verification has been modified, and you cannot reconfigure it, for example, required fields. Of course, you can do it inside your application, but it could cause inconsistency of user data in future.


The AWS Cognito User Pools provides a simple password verification as you can see below.


The good practice is to make a password validation inside your application to avoid unnecessary HTTP requests to AWS Cognito.


When the user went through the registration process, AWS Cognito can send a verification code automatically by SMS, or email to make sure the information has been entered correctly. This process is optional, and you can confirm the user manually by AWS Cognito console. Additionally, every access to the application can be verified by sending text messages. All that you need is to enable MFA functionality.


You can customize your verification message both on the email address and phone.



When creating the User Pool, you should define at least one application through which users will obtain access to the User Pool. The app, in User Pool context, is something like a gateway to your application. Each app has an ID and an optional secret key that have to be set up in the AWS SDK. You should not generate a secret key if you want to use JavaScript SDK for AWS Cognito. The reason is that JavaScript works on the client side, and everyone would see your secret key and would get unwanted access to your user pool.


In some cases, a good practice is creating a few apps in the user pool context. Because of this, you can very quickly revoke access for all users who, for example, use your application on a mobile device or via a particular browser.


One of the most interesting functionalities are triggers, which allow customizing the sign-up or sign-in workflow by assigning scripts created using the AWS Lambda service.


There are five types of triggers, which can help you to extend the sign-up or sign-in process.

  • Pre sign-up – This trigger is invoked when users submits their information to sign up, allowing you to perform custom validation to accept or deny sign-up requests.
    Examples of use:

    • Verify that the specified security access code to the application is correct.
    • Verify that the email domain is allowed.
    • In cases where a nickname already exists, send a variation by adding a random number to the end of the nickname.
  • Post confirmation – This trigger is invoked after a user is confirmed, allowing you to send custom messages or to add custom logic; for example, for analytics.
    Examples of use:

    • Create predefined set of files on AWS S3 bucket for each new user.
    • Send an email to system administrator that a new user has been registered.
    • Send a greeting email to confirmed user.
  • Pre authentication – This trigger is invoked when users submit their information to be authenticated, allowing them to perform custom validations to accept or deny the sign-in request.
    Examples of use:

    • Detect multiple simultaneous sign-ins at the same time and block access for new session after exceeding a defined limit.
    • Detect the technical break in the application and reject users, displaying a friendly message.
    • Force a password change after exceeding a specified period of time.
  • Post authentication – This trigger is invoked after a user is authenticated, allowing you to add custom logic; for example, for analytics.
    Examples of use:

    • Save number of the sign-ins for statistical purposes.
    • Send an email to user that sign-in occurred on his account.
    • When a user returns to your application after a long time of absence, you can send an email encouraging him to more often visits.
  • Custom message – This trigger is invoked before a verification, or an MFA message is sent, allowing you to customize the message dynamically.
    Examples of use:

    • Modify a message where you input user name and surname to welcome.
    • Different messages depending on the email domain.
    • Send-to-user wishes if the registration was made on his birthday.

AWS Cognito User Pools is quite an interesting solution thanks to the simple interface and availablility of different SDKs on the Android platform, iOS platform, and for JavaScript language. It simplifies the sign-up and sign-in process, which we can easily implement into our mobile or web applications without additional resources to build a backend app. Do not forget that AWS Cognito, apart from User Pools, has two other functionalities: federated identities and the synchronized data. Soon, I will show you how to use these three things in building a simple hybrid mobile application based on Ionic Framework.

Update 2016-07-28 Amazon Cognito Your User Pools – Now Generally Available

Tagged with:

Tags: ,