Pros and Cons of Using Amazon Cognito for User Authentication
Amazon Cognito enables you to quickly and easily add user sign-up, user sign-in, and access control to your web and mobile apps. At its core Amazon Cognito provides a complete solution for user authentication. Its main features are storing usernames and passwords, managing sessions, and providing forgotten password functionality. All you need to do is integrate with its endpoints. Well, that sounds cool. My app needs secure user login and why not have a well-known service by a big outfit like AWS manage our users and their credentials?
While this sounds great at the surface, all these features come at a cost. After having used Cognito across several projects with different requirements, we’ve found it may not be the best answer in all situations. You are restricted to how Cognito does things and heading down the path of custom configurations can be tricky, if even possible. Whether or not Amazon Cognito is right for you depends on your business needs.
Pros of Amazon Cognito
AWS takes all the responsibility off of you, the developer, to ensure your database is properly protected and passwords are securely stored. In fact, you don’t even have access to the users’ passwords. From a security standpoint this is great. Cognito also stores passwords meeting major compliance standards like HIPPA. When asked about your security practices you can simply refer to AWS following the industry best practices.
OAuth, SAML, and More
Not only does Cognito store your data securely but it provides all the functionality you need for an OAuth integration. No need to write your own code to manage user sessions and authentication tokens. AWS’ set of APIs allows you to simply issue calls to Cognito to validate tokens or get new ones. It even handles the sending of reset password requests, account validation, and pretty much any other user maintenance operation you can think of. It provides the ability to validate not only emails but phone numbers as well utilizing AWS SNS.
Aside from OAuth you can integrate with alternative identity providers. From Facebook to Google and even SAML, Cognito gives you the ability to add additional sign-in options for your users relatively easily. Custom-rolling all these integrations can be time consuming and Cognito gives you a uniform experience to present to your users.
A common use case is to use Amazon Cognito with API Gateway. It takes no time at all to set up your API to validate against a Cognito pool. This validation even happens before your API passes the call on to the next function, helping reduce the cost of having to validate sessions. This makes securing your endpoints trivial.
When you take in all the features it has above, it leads you to realize that you can very quickly and easily set up authentication in your application. Simply set up your Cognito Pool, hook into the API’s and you’re off and running. This is a huge benefit when you want to prototype an application or want to be able to focus on providing functionality in your application. Cognito helps you focus on what is important – those features that deliver unique value.
Another feature is Cognito’s Hosted UI. You simply enable the feature and a page becomes available for your users to login. Now you have a page that follows OAuth’s latest standards with no effort. The drawback to this approach is that the configurability and options for styling the page is rather limited. If you want to add complex styles or extra links you’re out of luck. Still, it’s a nice feature for getting off and running as fast as possible.
Cons of Amazon Cognito
Cognito does have a set of non-adjustable quotas – values you cannot change – and the list is rather long. For some of these values you’ll never have to worry about them, but others can be game-changers. For instance, access tokens cannot last more than 24 hours. This is a downside if you want long user sessions and don’t want to rely on a refresh token to keep that alive. Until recently that was a hard configuration, but they loosened it up to let you choose a time between 5 minutes and 24 hours. Other strict quotas include the time a user must validate their account or use a reset password link. These limitations may or may not matter for your application. It depends on your company’s requirements.
Better Setup Your Pool Correctly
We had a client requirement to use phone numbers to sign up users for their app. Great, not a problem. Amazon Cognito can handle this easily in conjunction with SNS. They assured us they would never want to use emails for signing up. (I know, famous last words.) So, we configured the pool to only have phone number for sign up. Fast-forward to post-launch, the client decided they need the option to sign up with email. OK, no problem, these things change all the time. But when looking at the pool configuration, we discovered that this wasn’t possible. For whatever reason, there are fields that cannot be changed after creation. And the way to get around this isn’t so straightforward. Guidance from AWS support suggested setting up a new pool that would be sync’d and used in conjunction with the old pool, which means managing two pools simultaneously in production – not ideal. This rigidity presents challenges for developing custom apps with changing requirements.
Integration with Outside Services
Cognito works great with other AWS services – SNS for sending text messages, SES for email and API Gateway for authentication, just to name a few. This is great for easy out-of-the box setup. But what happens when you want to change your SMS provider from SNS to a non-AWS service like Twilio? While technically possible, it’s not very straightforward. Now you have code split out into custom lambda functions, away from your main application. The result of all this is added complexity which translates to added cost.
Back in November of 2020, AWS had a major outage in the us-east-1 region. This crippled Cognito and, by extension, many applications that relied on it. Apps became non-functional, as you could no longer authenticate or validate sessions. This reinforced the need to have a disaster recovery plan for your cloud environment. In our article about protecting your application from an AWS outage we discuss Cognito and its shortcomings in this regard. To cut to the chase, at the time of this writing, Cognito does not have a regional fallback option in place like other services do. And this creates quite a headache for trying to recover your application in another region.
Should I Use Amazon Cognito
Amazon Cognito can be a great service. It’s secure, cheap, and easy to use right out of the gate. If you’re setting up a new prototype application, it might be a great choice. It will enable you to quickly focus on value-producing application features and give you the peace of mind of a secure authentication system. However, its rigidity can lead to complexity and headaches down the line as custom needs come into play and application requirements change.