When you build a new application, developing a secure, scalable user pool and authorization mechanism is a necessity and it takes time and effort to build. Sometimes, it even delays the development of the core features of your application that will bring the actual value to your business.
Amazon Cognito provides a scalable and secure user pool that you can create and use in your mobile and web applications. It provides a hosted user interface and SDKs for sign in and sign up actions. It has many features such as sending verification emails, SMS messages to your users. In this blog post, I will discuss how you can create an Amazon Cognito User Pool to use as an authentication mechanism in your applications.
Amazon Cognito
Amazon Cognito provides built-in authentication features such as sign up, sign in actions for use in your mobile and web applications. You can create your own user directories as User Pools or choose to provide SAML identity federation or authenticate your users through their social identities such as Facebook. In addition, Amazon Cognito Sync provides additional features enabling cross-device application syncronization for user data in your mobile and web applications which allow your users to use your application while they are offline and synchronize their data after becoming online.
Amazon Cognito also has an hosted-UI which you can redirect your users to sign in and define callbacks to your application after successful sign in. Besides, you can choose to develop your own front end using one of Amazon Cognito SDKs such as Amazon Cognito Identity SDK for JavaScript.
In this post, I will try to demonstrate how to set up a Cognito User pool and explain steps to pay attention during creation as well as some optional features.
Creating a User Pool on Amazon Cognito
You can start creating a user pool from Amazon Cognito dashboard on Amazon Cognito Console easily by giving a unique and descriptive name. Here, I will follow Step through settings instead of defaults to explain more details about sections that I find them useful to discuss.
Specifying User Attributes
The first section, Atributes, is the most important one, because you cannot change these settings after creation. I matched most of the section names below with their respective headers on Amazon Cognito Console.
How do you want your end users to sign in?
In this section, you define sign in methods for your users.
Choose Username if you would like your users to have a username. Besides, you can select whether they can use their verified emails or phone numbers. This means that, during sign in requests, your users would be able to type their usernames, emails or phone numbers in the same username field to authenticate. Amazon Cognito will handle the rest to find the correct user.
You can also allow your users to define a username that they can edit by enabling sign in with a preferred username. It is distinct from username which cannot be edited after created.
If you do not want your users to have a username and find it more convenient to use their emails or phone numbers, select Email address or phone number. Then you need to define whether they can sign in with both their phone number and emails or only one of them. Actually, Amazon Cognito users always have a username. However, if you make this selection, it generates a unique username for each user behind the scenes.
I realized that I find usernames easier to sign in instead of typing emails. But, I usually enable both of them for providing more choice.
Which standard attributes do you want to require?
Amazon Cognito User Pools follow Open ID specification. In this section, you define required attributes which your users will have to provide during sign up. In most cases, email is enough and you can provide additional attributes during sign up without making them required. You should also select phone number, if it is one of your preferred sign in methods in the previous section or you plan to provide multi-factor authentication for your users.
You can also define custom attributes in Do you want to add custom attributes? section if you would like to require your users to provide a custom information during sign up.
Policy Settings on Amazon Cognito
Unlike Attributes, the settings below can be edited after creation.
What password strength do you want to require?
This is where you define a password policy for you user pool. You have to set a minimum length for passwords. You can also provide more security by requiring passwords to have numbers, uppercase and lowercase letters and special characters. Special characters are one of ^ $ * . [ ] { } ( ) ? - " ! @ # % & / \ , > < ' : ; | _ ~ `.
If your users do not define passwords conforming this policy, they will be unable to sign up or set new passwords. With a few clicks, you can set, edit password policies without any efforts on development. Amazon Cognito handles them automatically.
Do you want to allow users to sign themselves up?
This is also a useful feature for various cases. For example, if you are building an application that will be used only by users in your company, you will probably select Only allow administrators to create users. An administrator will be able to create users and set a temporary password for them which Amazon Cognito will require to change them in their first sign in attempts. Your application should be able to handle this feature in its front end by redirecting these users to a page to set new passwords.
If a user is not used after being created by an administrator, it will be deleted automatically after an expiration set at How quickly should user accounts created by administrators expire if not used?. Amazon Cognito will clear unused users after this period.
If you are building an application that will be open to user sign up, then leave Allow users to sign themselves up checked. Again, administrators will also be able to users and previous information will apply when they do.
Multi-Factor Authentication (MFA)
You can enable your users to opt-in for multi-factor authentication or you may require them to do so. In default settings, it is not set.
Verification Requirements
You should select to verify your users emails if it is one of their sign in methods.
You can also enable phone number verification if you provide signing up with phone numbers or MFA. In this case, you need to create an IAM role to allow Amazon Cognito to send text messages and please pay attention that separate AWS charges would apply for sending SMS messages.
Other Useful Settings
Customizing Emails and SMS Messages
Amazon Cognito provides defaults for email and SMS messages. However, you can define prettier messages by customizing them in Message customizations section.
Email verification messages
You can select one of Code or Link features for your users to verify their emails.
If you leave
Codechecked, your email message should have a{####}text which will be replaced by the verification code. You need to handle code confirmation in your application by making necessary Cognito SDK calls.If you select
Link, Amazon Cognito will send a link in the email message for your user to verify his/her email.
Although it would be a generic front end, link option may be a better choice if you do not want to make effort to develop front end pages and SDK calls required. However, your users will need to remember to go to your website to sign in after confirmation. It may suit better for applications used within your company.
I find Code option to be more appropriate for customer facing applications, because your users will deal with pages customized for your application and can be redirected to sign in afterwards.
Invitation messages
You can edit your invitation messages after an administrator creates a user on Amazon Cognito Console. The only requirement is to have {username} text that will be replaced by the user’s username and {####} text for user’s password.
Using Custom Email Addresses
Amazon Cognito sends emails from no-reply@verificationemail.com. Wouldn’t it be better to use your own domain in from field such as no-reply@example.com? Amazon Cognito is integrated by Amazon SES which you can select one of your SES verified domain names. I might dive into SES verification in my future posts, but you can find a reference in the References section.
Finishing Creation and Creating a User Example
After reviewing your setup, click on Create User Pool and you are good to go. Let’s discuss creating a new user on Amazon Cognito Console.
Under General Settings, click on Users and Groups which will list your available users and groups. I will discuss this groups feature in future posts. Basically, you can assign groups to your users and customize your applications by defining restrictions according to these groups. For example, you can define a group for admins and implement a custom authorizers for your API gateway apis which you can authorize only if a user is in admins group to authorize for a specific endpoint.
Create user screen is standard, you will not see any required fields such as name although you selected in Attributes section. They are actually for custom sign up pages that make use of Amazon Cognito Identity Provider SDKs.
If you did not ask for phone numbers, uncheck Mark phone number as verified? If you do not have any custom application to send verification emails using Amazon Cognito SDKs, be sure to check Mark email as verified? to make the email verified. Currently, Amazon Cognito Console lacks an option to send email verification emails for users created by administrators.
If you select Send an invitation to this new user? and check Email, an invitation email will be send to the user’s email once creation is completed, providing username and password information as we discussed in Invitation Messages section.
Conclusion
Amazon Cognito User Pools provides simple tools to create a secure, scalable user pool for your applications which will allow you to focus more on your application’s business specific features. Even if you choose to create custom sign up/sign in forms in your application, the back end required for these processes will be provided by Amazon Cognito as SDKs which will make you more productive.
This post is an introduction to Amazon Cognito User Pools and I am planning to dive into more features in the future, such as creating custom Cognito authorizers for API Gateway, identity federation, user groups, etc.
Thanks for reading!
