4 Simple Features That Would Make a Big Difference to Cognito User Pools
Like many developers I avoided using Cognito for a long time. It just seemed too complicated. I only stared using it after AppSync was released because it doesn’t support custom authorizers.
After using it for a little over a year here are four features that I think would make Cognito User Pools much more useful.
Case Insensitive Usernames
Perhaps the single most annoying feature of Cogntio User Pools is case sensitive usernames. For some reason Cognito User Pools was designed so that
JOHN, and the other 13 possible variations are considered to be different users. This is probably the single most complained about feature.
Adding a flag to support case insensitive usernames is my number one feature. For new Cognito User Pools this should be the default setting but existing user pools may require case sensitive usernames for backwards compatibility.
Make Email Address Unique
If case sensitive usernames are the most complained about feature then email aliases are the second most complained about. In most applications you cannot register the same email address twice with different users. This signals to the user that they already have an account and they should perform a password reset.
Unfortunately if your using username logins then Cognito User Pools will simply move the email alias to the new account. Once the unfortunate user realizes they’ve created a new account it’s now too late to perform a password reset. To avoid this I’ve been configuring my Cognito User Pools to use the email address for the username which stops this problem.
A simple flag to prevent aliases from being moved could solve this problem.
Better CloudFormation Support
There are two different problems with CloudFormation support for Cognito User Pools:
First, there are a number of Cognito User Pool options that cause the user pool to be replaced when changed using CloudFormation but not when they are done via the UI. It defeats the purpose of keeping your infrastructure in code under version control when you’re forced to use the console to make changes in order to prevent your users from being deleted.
Second, not all of the Cognito User Pool settings can be configured via CloudFormation. For example: CloudFormation supports many but not all of the Lambda triggers that Cognito User Pools has. If you want to set one of the triggers that it doesn’t then you’re mucking around in the console and your infrastructure is no longer under version control/contains manual steps.
The lack of OAuth support makes it difficult to integrate Cognito User Pools with third party authentication services. I know they support OpenID Connect which is built on top of OAuth 2.0 but very few companies support that.
It feels like OAuth should be rather simple to implement. The flow doesn’t change between providers. You could build the OAuth flow into Cognito User Pools then use Lambda trigger at key points to:
- Generate the redirect URL
- Verify the callback
- Fetch user information
AWS would only need to develop one or two providers as examples and the community would quickly fill in the missing providers.