Connect AWS Cognito to Database

AWS Cognito is very powerful system of managing users. It manages a lot of things for us as far as user management is concerned. Trivial tasks like login, signup, federated login with third party, forgot password, user confirmation etc are handled seamlessly with the help of AWS Cognito.

Developers use these kind of user management services so that they can spend less time in user management and more time in developing actual services. Another benifit of using such services is seamless integration provided with other cloud services. For example we can authenticate users from cognito with API gateway. And many developers, hosting their apps on servers or using serverless stacks, handle their data in one or more datastores.

One of the trivial task is to successfully connect cognito and their database for every users in the system. AWS Cognito has two features that makes this connection very seamless.

From Cognito to Database, Using Triggers.

Cognito has a usefull feature called triggers, they have triggers for various actions at various stage of authentication flow. There are triggers to validate data before signup, triggers to customise messages for verification etc. These triggers send their data to lambda functions, where we can customise any logic that can fit our user flow.

While signing up, we can send some data to signup that matches with attributes like name, email, phone number, gender etc. Cognito sends these attributes to triggering lambda. We can use these triggerring lambdas to store the data in our database.

Our first best shot to get logged in user’s data using Post Authentication trigger. This trigger will be invoked when User is successfully authenticated. But I suggest and personally prefer to use Post Confirmation trigger.

Cognito has confirmation flow, where user is sent a confirmation code as soon as they signup successfully. This is to ensure user does not sign-up as an accident or as an afterthought¹. By asking the user to confirm the signup, cognito makes sure the user actually wants to use (or explore) the service bit more seriously. Once user confirms the signup, cognito will send user data in Post Confirmation trigger. This is where we should add the user to our database.

This is one way to connect cognito to our database. Now we’ll see how we can connect our database to cognito.

From Database to Cognito, Using custom Attributes.

There are many attributes that can be mapped with Cognito’s user data. As stated below, cognito has some default attributes like address, birthdate, first name, last name, phone number etc. These attributes help us to identify a user but don’t help us to link that user to database, leaving us two duplicate users, one in cognito and other in database.

We can solve this issue by creating custom attributes. We can creat as many custom attributes as we like. We can set them, allow them to limit to defined length and decide whether to allow these attributes to get updated or not. We can either allow string or number as the value of these custom attributes.

As seen in above screenshot, we decide the value type of custom attribute, name the attribute. If the value is string, we can define minimum and maximum length, if the value is number, we can define minimum and maximum value. Checkbox that says mutable indicates whether the value remain same throughout the user’s lifetime or it can be changed by any client.

Once created, the attribute name we have provided will be prefixed with custom:.This will separate this from default attributes, and that’s how it will be accessd, for example an attribute of userId will become custom:userId and we can access this attribute in our code using prefixed name. Creating any custom attribute is one-time, immutable change. We can not change any property of this custom attribute once it’s created. So if we’re not happy with the attribute created, it’s better to leave that as it is and create a new one with desired configuration.

When we have our user id, we should call admin update user attributes method from AWS SDKs of the language (or CLI) we are using on our server or lambda.² That will update (or create) an entry of custom:userId in cognito user’s page. Once included, this information will be propogated to any tokens created for this user. Which will help us to connect cognito users with the users in our database.

That’s how we can connect cognito users to our database.

Some points to take care of.

1. First and foremost, unless mentioned otherwise all lambdas triggered by Cognito must return within specific time (which is at the time of writing is 5 second). If the lambda does not return within that time, cognito considers this as failure and sends the same data back to trigger. If you’re not careful enough, you’ll end up with duplicates.

2. Length of custom attributes are limited, you can’t set a string which can accept a whole novel. For string attributes we can set max 1000 characters.

3. Tokens on Cognito are often long lived, you should not store data on cognito which changes often.