I Used AWS Cognito for a Startup. I Wouldn't Do It Again
A developer recounts their painful experience implementing AWS Cognito for a startup's authentication. They describe confusing documentation, breaking changes in Amplify v6 that forced a rewrite, painful local development, limited customization, and a configuration mistake that required a user migration. The lesson: prioritize developer experience over ecosystem convenience, and test with a proof of concept before committing.
Authentication logic that was working perfectly fine in production had to be rebuilt because the library maintainers decided the old API was no longer the blessed path.
- wilkystyle
> Reading Cognito docs feels like someone took three separate manuals, threw them in a blender, and then sprinkled in some outdated Stack Overflow answers for flavor.
This is my experience with basically all of AWS documentation. It is nearly always either (1) far too high-level to be of any actual use, or (2) far too verbose, with a massive volume of superfluous information I need to parse and discard before I get to the stuff I am trying to figure out.
As just one example, I recently needed to link an AWS Partner Central account with an AWS Management account, and process and documentation was painfully complicated: https://docs.aws.amazon.com/partner-central/latest/getting-s...
- solatic
> Next time, I’m picking a tool based on developer experience first, not AWS service integration convenience. The time we lost debugging Cognito issues could have paid for several years of a paid auth provider.
How many paid auth providers let you export user password hashes so that you can seamlessly migrate to another vendor, if you want to?
The whole problem with auth is that both (a) login screens are shown to unauthenticated users, which is a superset that includes attackers, who will do everything from DDoS to crafted malicious input to try to grab user secrets, so you really want to pick something that is already running at large production scale and with all the production battle-scars, and (b) that need to go with a managed vendor is very much in tension against local development, vendor independence, data portability, and other Good Engineering Practices (TM).
Sure, AWS Cognito sucks. In many ways, the product feels stuck. Making compromises to get stuff shipped, working, and stable sucks. But honestly, unless you're going to prefer (b) over (a) (and there are times to do so, in particular with intranet applications behind a firewall that aren't really susceptble to those kinds of attacks) and pick something like Keycloak, you could do a lot worse than Cognito (shudder, Okta, shudder).
- patwolf
My experience with Cognito matches the author's experience exactly. I mostly used Auth0 in the past, but we switched to Cognito for a new project because it would be cheaper.
Don't like that email addresses are case sensitive, and now you want to change that? Sorry, you gotta create a new user pool from scratch--no way to migrate.
- mannyv
I remember talking to the Cognito team about password reset and arguing with them that being able to set a password was a required feature. They were like "no, why would you never have to not go through the reset flow? That's a security problem." Then of course they added it in a few weeks later because every admin needs to do that. So at some point they had a bunch of people working on it who had like zero operational experience.
Two benefits to Cognito are (1) it allows you to log into a service without having any credentials locally, and (2) that Cognito identity allows you to provide access to AWS resources. You can probably do that now, but plenty of solutions still require an on-device key...which is an obvious security issue.
Also, using your own backend for authentication made it easier to manage things because your auth wasn't trapped inside Cognito.
- cldcntrl
Cognito has real rough edges, this article doesn't really mention any of them.
If you've ever tried to implement, say, a working SAML integration through Cognito, you'll know how obscure the flow is. I've had to work with the Cognito team to get real showstopping bugs fixed.
Definitely not AWS's most polished service, but workable if you know the ins and outs.
- mikigraf
Don't even get me started on backups or other basic functionality one would expect from a service like this. AWS should either make an acquisition (Auth0 or a smaller company like Wristband?) and rebuild the service, or just kill it. Instead, we have a critical service that enterprises rely on stuck in limbo...
- nater5000
I don't disagree that AWS Cognito isn't the easiest auth service to work with, but once you figure it out, it works just as well as the others.
I've experienced the same exact pains (and many more) that the author described. But the thing is that once you've experienced those pains, you know how to deal with them. In software, you just have to figure it out once and then it's done.
I can't say I scaled Cognito usage to anything massive, but I can say that keeping everything in AWS is worth the hassle (at least depending on the context). Cognito provides plenty of options of actual customization (the hosted UI is only good for initial testing, then toss it). And, of course, LLMs are able to deal with Cognito just as easily as any other auth service. I didn't have the luxury of using LLMs when I set up Cognito, but it's still my go-to for auth and Claude doesn't stumble on it.
- dabinat
Personally I would never build my business on a technology tied to a specific vendor that makes it difficult to switch if said vendor delivers a poor service or massively raises the price.