Just use whatever service that costs 10x as much to make it do what it was advertised to do in the first place, like DAX for dynamo or cloudfront for S3 in case you hit “scale” like 2000 req/sec
At least it's formatted readably and they took the time to ask the AI to make it less AI-like. The tone is annoying but I try to focus on the message and not how it's communicated.
You'd think making AI do the annoying integration work would mean less complaints about terrible docs and API.
> 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.
That’s my experience with any of the 3 hyperscalers when reading docs. Millions of versions, blog posts and just overall massive challenge to get to the root of it. Funny the one thing I was always able to immediately and quickly digest, AWS Textract because they have a great python library with the kind of documentation I expect from a python project.
> That’s my experience with any of the 3 hyperscalers when reading docs.
I used to hate the AWS docs, now I use Azure and I hate that so much more. At least AWS had loads of (bad) docs that you could string together to figure out how to do something. With Azure, there's just no docs (except for bad videos), and they literally tell you (at the top of every page) that you can do this with AI (I know I can do it with AI, but I'd prefer if I could read your docs to make sure the machine isn't doing something dumb).
My expectation is that I'll end up on GCP in a few years, and that will be bad in hilariously different ways.
I feel like I'm the only person on HN that doesn't have any major (or cliche) problems with GCP, even after using it for a decade at this point. Like it's not perfect and I've hit weird roadblocks along the way but I've dabbled AWS and I currently use Azure at work and those are hilariously bad in their own ways, people just seem to kind of be used to it?
To be fair the jokes about GCP are pretty accurate. Although the documentation isn't that bad when it exists, there's just not that much of it, you better not be trying to do anything uncommon.
But then I look at Azure and I'm not laughing. I don't know what is going on at Azure, but in some areas the docs straight up do not match reality. And then the weird error codes you randomly get out of Azure are, I assume, only understood by God and one guy who had been quietly working at MS for years but was replaced by Copilot, and now only God knows.
I like GCP as well, having previously used AWS for many years.
The biggest issue is that it's taken Google a long time to figure out what enterprise security is - it's not something what was in their DNA - and the product shows it. They're too focused on weird fancy half-assed "beyond" solutions to properly implement the basics. They dangle clever federated etc. solutions that only work in some circumstances so that you're better off just avoiding them, but the more basic alternatives are limited in their own way because they focus too much on the fancier solutions.
I find GCP's developer experience to be superior to AWS. Maybe it's just me, but I found Cloud Run to be super simple to use compared to ECS/Fargate. The "gcloud" command structure also makes more sense to me.
My experience with Boto: need some S3 manipulation logic, here is an official documentation that shows how to solve the exact problem with Boto, one caveat, this version of Boto is deprecated. Do the same with the newest version? Not possible.
I do not really want to defend any of the companies here but the reality is that documentation is always a thankless job. People do it to get their project out there, get limelight and move on. There is not much incentive for the teams to manage the documentation actively unless the its a business priority.
I am myself in the IDP business, was trying to understand the pain points of the user. Even though I am not big fan of AWS but I find that the concerns are baked into the hope that using an IDP would some how make is very easy
> Flexibility of doing local development while on plane
Really depends what you are expecting from the IDP but personally this is one off situation and in most cases its not worth solving. We are in such a interconnected or dependent state where local development without internet is really hard.
> Configuration issue
The features of a solution are two edged sword, it provides people options to tailor it for their own use case and yet at the same time it adds to the learning curve. Good default might have been useful here, however it looks like Author only wanted email and nothing else so it was a departure from defaults
> UI customization
A lot of providers allow some flexibility with the UI but not a whole lot. And then some allow you to host on your website and call the API's for the authentication flows using SDK. Personally this one is tricky, its a UX vs security topic. As a thumb rule never trust the client. The request headers and ability to interact with browsers are what provides you with relatively better state and session control. As an IDP provider I do not want to loose that and still be on the hook for security.
> As a thumb rule never trust the client. The request headers and ability to interact with browsers are what provides you with relatively better state and session control. As an IDP provider I do not want to loose that and still be on the hook for security.
ok so why NOT allow extreme ui customization since client is untrusted anyway? i dont get it. theres no security concern (within this ui) bc the whole thing is untrusted.
I always say that AWS docs are exhaustive, but exhausting. Mostly because they're spread across half a dozen places. The answer you need is normally in there somewhere, but good luck finding it. And when I remember the docs contain some fact I want re-reference, I can never find it again.
Most of my interactions with AWS docs end up being pretty useless, as in they are information-free. Like describing how to fill out a form and press next in a wizard which boil down to "fill out the Name field with a name and press next" and every once in a while there will be a tiny amount of information but most of it is useless and usually the information you're looking for isn't there.
Nobody using AWS needs to be told "in order to add a hoozit, press the add hoozit button, fill out field A then fill out field B then fill out field C and then press next"
Now there's an interesting idea, have an LLM crawl their entire docs and cull everything obvious or content free and compile what's left
I recently implemented CloudFront signed urls where my app uses KMS to sign the url. Sounds simple but app is not documented to work. And there's a bunch of anecdotal docs and reports that it doesn't work. But very recently (April) Cloudfront and KMS, for the first time ever, both started to support the same key algo/size. So it's secretly now possible, but I have never seen a recipe for it. So AI doesn't know about it either.
I was able to stop managing and rotating TLS key pairs, replicating public keys globally to my apps.
>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.
Had to go through the exact same process of linking Partner Central with Marketplace. The console suggested following multiple video tutorials and linked to docs that may be outdated.
They have this AI tool on every page that links to the same content or references settings panes without linking anything.
I love it when I read some AWS docs to get a feel for what to do, start to build things, find something that seems like it should just work, then do a lot of digging to figure out what I'm doing wrong, only to find a slightly different page of pretty much the same documentation stating whatever I was wanting to do just isn't supported and can't be done, and I've just wasted a day or two trying.
when LLMs first became popular my first real use for them was to find information about AWS services. LLMs have read it all and can (mostly) synthesize what you ask if it is in the docs.
Regardless of AI gen'd article... Cognito does have some rough edges. One day I'd like to make a best practices Cloudformation template (if doesn't already exist) that includes things like which login name to set, notification lambdas and the like.
AWS documentation is the best excuse to stay away from their services. I thank everyday for their documents, it's like putting a lighthouse on an iceberg.
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...
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.
That’s really the worst feature of it. When you first set it up you’re asked at least a dozen questions that you probably have no idea what they mean. But you have to pick something. And whatever you pick on that first day setup you are stuck with FOREVER. Unless you do a complex data migration task.
Also, want to migrate to a different provider? Sorry. You can’t get the hashed passwords out. So if you do a migration it will be painful to users since they’ll have to do a password reset.
Ory Kratos has a password migration hook that lets you migrate password credentials out of anything (including Cognito) without password resets.
I believe most other (modern) auth vendors have an equivalent.
I really don't see any reason to be using Cognito in $currentyear.
Auth0 will run an export for you, but you have to file a support ticket for them to do it, and it may take them a bit of time, so you may end up with some users who get reset to a slightly old password (if they change it between the export and your import) or if you get a new registration.
Given all the pain I've suffered working with both cognito and auth0, I can't imagine a reason for using either in $currentyear.
> 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).
Counter point: How many paid auth providers force you to create an entirely new deployment and then use a lambda to migrate within their own system? Especially for something as seemingly simple like adding another metadata field?
I think they allow export because they drew some interesting lines around their own mutability concerns.
Auth0 and Firebase both let you export user password hashes (though I believe you need to open a support ticket in order to do it in Auth0's case at least).
I think Cognito is actually one of the few with absolutely no path to achieving this.
Entra External ID does not allow export of password hashes.
It actually doesn’t allow a whole shitload of stuff that should be there by now.
For example, it supports passkeys, but has no UI for adding or managing passkeys. You have to build that yourself. In a separate app, on a separate domain.
Personally I feel the password migration feature should never be supported. Its ripe for abuse once you open up a pathway to it. SCIM as a protocol was meant to solve this problem, if everyone could just implement it.
This is a terrible suggestion. Rolling your own auth nowadays is like rolling your own encryption. It’s just a bad idea. OAuth and OIDC are massive specs that are constantly changing and you’re going to be stuck chasing and developing auth instead of your actual product.
I know because this is what my brain dead principal engineer did and I’ve spent the last 3 years chasing RFCs and am now going to spend the next year migrating to Keycloak because I’ve finally convinced my boss that we’re not an auth company.
I agree you shouldn't write every line by hand, you should use libraries, but pretending like OAuth/ODIC require using something like Cognito/Auto0 is just silly. An LLM can crank out the needed code in very little time and give you full control over your auth instead of fighting an auth provider at every turn.
The number of compromises something like Cognito requires are just not worth the perceived gains.
I really whole heartedly disagree and if you think it’s silly I think that you don’t really fully understand the complexity of it. An LLM doesn’t solve everything. You still need to understand the spec, become a domain expert, and design your solution for the parts that the RFCs leave open with undefined behaviour. At the very least if this is your opinion you should start with an open source solution like Keycloak or authentic and fork it if you really need “control”.
I already said that using a library (open source) is a good idea, I just don't think we need to pretend that Auth is so complicated that we need a third-party provider. I don't buy that argument. You should not roll your own low-level code, you should never need to even look at the RFC's, just hook into the Auth library you use (library, not service).
I built a product on Cognito in 2017-18 or when it was, and already back then it felt semi-abandonded. Thankfully that particular product never really took off and we didn't have to spend too much time on wrangling Cognito.
Feels like there are a few categories of services from cloud providers,
There’s the basic infrastructure we know and love like S3, EC2, etc.
There’s the higher level but still basic stuff that just makes a lot of sense. I like ECS + Fargate, Lambda, DynamoDB, SQS.
And then there are the tarpits. CloudFormation. Cognito. Step Functions. API Gateway. They do something useful (otherwise why would they exist?) but the main point of their existence seems to be to trap you in AWS, and the fact that they solve a problem seems secondary. Some of them are cheap (CloudFormation is free!) but in general they seem like expensive alternatives to simpler, cheaper solutions.
The further up the stack you go, the worse it gets - but, honestly, Cognito and API Gateway are merely mid-tier.
The really nightmarish ones are the likes of CodeStar, AppRunner, Directory Service, CodeCatalyst, and 90% of anything under the Systems Manager heading. Things that tend to be glued together from multiple lower-level services with a sprinkling of vendor lock-in on top.
I found "Systems Manager Session Manager" (terrible name!) useful a few times for getting around network restrictions.
You set up a EC2 VM, which doesn't have to be in a public subnet, then use "session manager" to forward ports to other instances / services using the AWS CLI. It is possible for that stuff to be blocked with IAM but often it's overlooked since IAM is confusing enough as it is.
I’ve been pondering a deep dive into Keycloak or Ory. Or is WorkOS good enough for the price?
I’m looking to centralize account management across multiple systems.
Keycloak is a big complex java app that does everything in one service, clustering and everything, all kinds of plugins and stuff you can make it do what you want at a price.
WorkOS has messed up SCIM integrations for us/our customers serveral times, and now with agentic stuff I'd just build out SCIM support myself (done it pre agents so maybe not for everyone), they're also kinda expensive and have hard lockin since they're not going to hand out your customer SAML/SCIM/whatever configs and password hashes.
Ory's got a nice cloud offering (only used it self hosted) but the whole stack is there and it's IMO easier to understand than keycloak (and you probably don't want to build your own)
I would also rather admin/bug fix/operate a go service than a java service (personally). Keycloak is not terrible though you have enough rope to really get yourself in a bind.
We've been using Keycloak for a while, it's definitely not bad, but there are times when it's been frustrating, and getting it both stable and scalable seem to be incompatible goals.
It's super powerful and can do whatever you want it to do (at least if you are comfortable writing Java SPI). But there's a lot of knowledge of how to set things up that takes time and is not readily acquired.
For the record we looked at Ory early on, but it was not mature enough and didn't offer a full IdP stack at the time. We've since looked again and found there to be some conventions around how it works that made it hard for us to consider migrating from Keycloak.
I share the OP's pain we chose to use cognito for the exact same reason and I've had the exact same pain however the evaluation of itself takes time and the inconvenience OP is suffering with is only a function of having users.
If I were starting my startup again I would, in almost every instance, trade problems if we have some success for reduced decision fatigue at the start.
This may now mean something along the lines of "struggling to grind through..." but is based on the original meaning of having sex without a condom, typically with misogynist overtones. You might want to avoid it for this style of writing and audience.
Not really. The term is a shortened version of "sucks eggs", which is originally from Shakespeare and used to describe an odious creature or habit (a weasel in Shakespeare's case).
I've used AWS Cognito for two start ups. One is still trucking. Cognito definitely leaves a lot to be desired, but overall I've never encountered any major issues with it. I think it's cheap precisely bc it's lackluster, but that's fine for my needs. YMMV I guess
129 comments
[ 0.25 ms ] story [ 8.8 ms ] threadLike how scammers put in typos
You'd think making AI do the annoying integration work would mean less complaints about terrible docs and API.
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...
I used to hate the AWS docs, now I use Azure and I hate that so much more. At least AWS had loads of (bad) docs that you could string together to figure out how to do something. With Azure, there's just no docs (except for bad videos), and they literally tell you (at the top of every page) that you can do this with AI (I know I can do it with AI, but I'd prefer if I could read your docs to make sure the machine isn't doing something dumb).
My expectation is that I'll end up on GCP in a few years, and that will be bad in hilariously different ways.
There are two ways to do everything; one is deprecated and the other is not yet feature complete.
Glad to know that they're allowing their customers a taste of what it's like to work at Google.
But then I look at Azure and I'm not laughing. I don't know what is going on at Azure, but in some areas the docs straight up do not match reality. And then the weird error codes you randomly get out of Azure are, I assume, only understood by God and one guy who had been quietly working at MS for years but was replaced by Copilot, and now only God knows.
The biggest issue is that it's taken Google a long time to figure out what enterprise security is - it's not something what was in their DNA - and the product shows it. They're too focused on weird fancy half-assed "beyond" solutions to properly implement the basics. They dangle clever federated etc. solutions that only work in some circumstances so that you're better off just avoiding them, but the more basic alternatives are limited in their own way because they focus too much on the fancier solutions.
I am myself in the IDP business, was trying to understand the pain points of the user. Even though I am not big fan of AWS but I find that the concerns are baked into the hope that using an IDP would some how make is very easy
> Flexibility of doing local development while on plane
Really depends what you are expecting from the IDP but personally this is one off situation and in most cases its not worth solving. We are in such a interconnected or dependent state where local development without internet is really hard.
> Configuration issue
The features of a solution are two edged sword, it provides people options to tailor it for their own use case and yet at the same time it adds to the learning curve. Good default might have been useful here, however it looks like Author only wanted email and nothing else so it was a departure from defaults
> UI customization
A lot of providers allow some flexibility with the UI but not a whole lot. And then some allow you to host on your website and call the API's for the authentication flows using SDK. Personally this one is tricky, its a UX vs security topic. As a thumb rule never trust the client. The request headers and ability to interact with browsers are what provides you with relatively better state and session control. As an IDP provider I do not want to loose that and still be on the hook for security.
ok so why NOT allow extreme ui customization since client is untrusted anyway? i dont get it. theres no security concern (within this ui) bc the whole thing is untrusted.
Nobody using AWS needs to be told "in order to add a hoozit, press the add hoozit button, fill out field A then fill out field B then fill out field C and then press next"
Now there's an interesting idea, have an LLM crawl their entire docs and cull everything obvious or content free and compile what's left
I was able to stop managing and rotating TLS key pairs, replicating public keys globally to my apps.
I guess that's what they trained Opus 5 on
They have this AI tool on every page that links to the same content or references settings panes without linking anything.
Fun times.
Being useful to a human is incidental side effect.
One big pro about cognito.. can't beat the price.
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.
Also, want to migrate to a different provider? Sorry. You can’t get the hashed passwords out. So if you do a migration it will be painful to users since they’ll have to do a password reset.
Yes it’s cheap. But you get what you pay for.
I really don't see any reason to be using Cognito in $currentyear.
Disclosure: working for Ory.
Given all the pain I've suffered working with both cognito and auth0, I can't imagine a reason for using either in $currentyear.
Linux/BSD as the identity/runtime layer, SSH is the protocol boundary, and your web backend is the command gateway.
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).
I think they allow export because they drew some interesting lines around their own mutability concerns.
I also would never use cognito again.
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
I think Cognito is actually one of the few with absolutely no path to achieving this.
It actually doesn’t allow a whole shitload of stuff that should be there by now.
For example, it supports passkeys, but has no UI for adding or managing passkeys. You have to build that yourself. In a separate app, on a separate domain.
I'm struggling to think of one that's refused in my experience.
Clerk is surely one of the biggest and allows you to do this.
I know because this is what my brain dead principal engineer did and I’ve spent the last 3 years chasing RFCs and am now going to spend the next year migrating to Keycloak because I’ve finally convinced my boss that we’re not an auth company.
The number of compromises something like Cognito requires are just not worth the perceived gains.
There are lots of good options out there that enterprisey abominations.
There’s the basic infrastructure we know and love like S3, EC2, etc.
There’s the higher level but still basic stuff that just makes a lot of sense. I like ECS + Fargate, Lambda, DynamoDB, SQS.
And then there are the tarpits. CloudFormation. Cognito. Step Functions. API Gateway. They do something useful (otherwise why would they exist?) but the main point of their existence seems to be to trap you in AWS, and the fact that they solve a problem seems secondary. Some of them are cheap (CloudFormation is free!) but in general they seem like expensive alternatives to simpler, cheaper solutions.
The really nightmarish ones are the likes of CodeStar, AppRunner, Directory Service, CodeCatalyst, and 90% of anything under the Systems Manager heading. Things that tend to be glued together from multiple lower-level services with a sprinkling of vendor lock-in on top.
You set up a EC2 VM, which doesn't have to be in a public subnet, then use "session manager" to forward ports to other instances / services using the AWS CLI. It is possible for that stuff to be blocked with IAM but often it's overlooked since IAM is confusing enough as it is.
WorkOS has messed up SCIM integrations for us/our customers serveral times, and now with agentic stuff I'd just build out SCIM support myself (done it pre agents so maybe not for everyone), they're also kinda expensive and have hard lockin since they're not going to hand out your customer SAML/SCIM/whatever configs and password hashes.
Ory's got a nice cloud offering (only used it self hosted) but the whole stack is there and it's IMO easier to understand than keycloak (and you probably don't want to build your own)
I would also rather admin/bug fix/operate a go service than a java service (personally). Keycloak is not terrible though you have enough rope to really get yourself in a bind.
It's super powerful and can do whatever you want it to do (at least if you are comfortable writing Java SPI). But there's a lot of knowledge of how to set things up that takes time and is not readily acquired.
For the record we looked at Ory early on, but it was not mature enough and didn't offer a full IdP stack at the time. We've since looked again and found there to be some conventions around how it works that made it hard for us to consider migrating from Keycloak.
Personally I choose Keycloak, but Ory is not a bad choice at all if you are willing to do more upfront work.
Why use AWS for any size company?
We mainly choose it because AWS was used anyway and the security aspect seemed to be solved entierly with this coice (if aws get's hacked ... ).
We regretted it out of similar reasons.
If I were starting my startup again I would, in almost every instance, trade problems if we have some success for reduced decision fatigue at the start.
On another project people didn't get this advice and we spent a two weeks working around the limitations to scrap it eventually.
This may now mean something along the lines of "struggling to grind through..." but is based on the original meaning of having sex without a condom, typically with misogynist overtones. You might want to avoid it for this style of writing and audience.