> 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.
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.
> 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?
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.
They get promoted for fucking with them. We were in the middle of a big fight with Microsoft support over a product defect. They literally updated the product docs in realtime and revised the sizing guidance for the product to be about 5% under our sizing. It was too specific a number to be a coincidence.
We were at war with them, so the team was capturing the documentation and timestamping it. They gaslit us to run the clock so the product would slide outside of mainstream support.
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.
>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 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 for accessing S3, where my app uses KMS keys to sign the url. Sounds simple and obvious but for the entire history of Cloudfront and KMS it was not! It is not documented to work, nor could I find any explicit AWS documentation saying that it wouldn't work either. And there's a just bunch of anecdotal reports (blogs, github issues) that it doesn't work. But very recently (April I think) Cloudfront and KMS, for the first time ever, both started to support the same key algo/size. So it's now possible, but I stumbled on it, and have never seen a recipe for using them together. So AI doesn't know about it either!
I was finally able to stop managing and rotating TLS key pairs, replicating private keys globally to my apps.
So: who really reads those little boring announcements, and connects the dots? Seemingly, not even AWS themselves!
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.
> 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.
Yup for the Ory managed service (Ory Network) you can export all data through the admin API including hashed passwords.
Of course when self-hosting Ory you have full control over the database as well.
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.
Yea I went through this as well - when I tested it, they also required you be on a paid plan to even be able to get the export, which is kinda crazy. I work at an auth company now (Clerk) and this experience drove our current approach, which is that you can instantly export all your user data through a button in the dashboard. Maybe it's not as "sticky", but I think respecting your users when they want to get their data or migrate off is way more important.
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.
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...
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.
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.
When evaluating a third-party service like Cognito in this case or a mail provider, I either require that it uses an open standard for access like SMTP or the interface that I need to use is small enough that I can wrap it in my own layer of indirection so I can easily mock it and swap it out later. Most of the time I never switch it. But god damn, does it feel good to know that I can move if I need to and I'm not locked in.
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.
Lots of really thorny gotcha's relating to their proprietary triggers that aren't documented anywhere.
You will end up having to talk to their devs and inevitably get answers that are some flavor of "pay for enterprise, but you can't test to see if it actually solves your problem".
It can also be very expensive and messy to setup developer environments since there is not self-hosted option.
I haven't used it in a professional setting since the Okta acquisition, but I can't imagine it has gotten any better.
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.
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.
I used to be an architect with a bag of pro certifications for the world's largest AWS services provider/developer/reseller (we even did a lot of work for Amazon.com themselves). I gave it up a few years ago when it became clear that for most people, moving OUT of the cloud was a far better move than moving IN.
In a lot of ways, I really love AWS, but most of the high-value services are increasingly flaky and questionably supported, and nearly all of them have (often not very obvious) lock-in barbs.
For a while, cloud native development actually made sense. But as Cloud services have converged to become just big Kubernetes providers with API sprinkles (whose syntax is often more vinegary than sugary), there is less and less value there.
Add to that that almost no companies really need a huge cloud-based system to run their businesses, and that $500-2500 computers literally outstrip the performance of supercomputers from around the turn of the century in every respect, and there is less and less real need for cloud services...
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.
The documentation complaint is true of many, maybe all, AWS services: they discuss multiple generations, address multiple target audiences, and range wildly in currency and relevance, from marketing material to technical deep dives, all intermixed.
Cognito itself is a very AWS tradeoff. It's delightfully inexpensive. It quite effectively protects one of the most relentlessly attacked parts of any web service. It supports workflows essential as you scale, like SAML federation ("single sign on/SSO"). It basically works, day in and day out.
But OMG, the sharp edges! It has sharp edges to spare, even compared to other AWS services, for which sharp edges and exposed corners are just par for the course.
Then you try to go the next step, e.g. add multi-region disaster recovery and failover. That seemingly straightforward requirement to scale up is "left as an exercise for the reader."
Cognito has all the virtues of a utility service, including the developer experience.
In a previous greenfield project (pre-LLM) I considered using Cognito since I was all-in on AWS (Lambda, DynamoDB, ApiG, Route53, S3, SQS/SNS, and the list goes on...) but after reading through the docs I wanted to pull my hair out. What I thought was going to be a time-saving measure turned into a quagmire. Even with my level of "lock in" I was not willing to hand over auth and so I rolled my own (and it worked fine).
Nowadays I can't imagine using a 3rd-party for something like auth (or many other things) due to lock-in and also just always needing to conform to their way of doing things.
Apologies for the non-sequitur but 2 days ago I saw FreshDesk had deleted my account (free plan) that I had been using (sparingly, <50 tickets total if I had to guess) for 3+ years. No email, no notice, just deleted my account and broke the sites that I had integrated their feedback widget into. I reached out to see what was going on and they pretty much told me I had to upgrade if I wanted my account back.
Now 1-2 years ago I would have considered paying. In fact I would have considered paying IF they had contacted me to say "pay up or we will delete" but the fact they deleted it without any contact meant FreshDesk was dead to me. I started, for all of 1 minute, to consider the alternatives before I fired up Claude and in <2hrs I had a full replacement for all the parts of FreshDesk I was using (basic ticketing, emails, statuses, file upload).
The build-vs-buy decision has completely flipped for me. I have a hard time thinking of paying for something my platform depends on, especially auth, when it's so easy to build it now.
Side Note: that "all-in" AWS project? Yeah, with Claude's help I'm off 90% of the AWS's services and while it's still hosted there I can move to any VPS if I want now that I've removed my dependencies on AWS-specific concepts. It's been glorious and it has the side effect of meaning my local dev more-closely matches the deployed code since there isn't AWS-magic I have to fake anymore.
Auth is a bit of a different beast when it comes to the build vs buy debate though. A competent auth provider has the infrastructure (and necessary data) to deflect against DDoS attacks, bots, etc.
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
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.
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
I did some work for a sizable org who were pursuing a migration from their in-house auth to cognito. They originally scoped it at two months, and it ended up taking them six to roll it out.
Then they figured out that their cost projection was actually off by an order of magnitude. And also kept getting bitten by peripheral systems newly getting out of sync.
And so then, they embarked upon the journey to roll it all back...
AWS is good at operations, i.e. running something like S3 at massive scale. Or SQS, ddb, etc. High surface area for distributed systems, but low surface area for user experience.
Once you add in product decision making, like how to make the dev experience good on something with alot of user flows (like cognito), the products are shit.
Yeah good example of this also with the agent stuff they are pushing now, documentation can read to be sales-like and then as you start using it stuff starts to fall apart. At this point there are better open source alternatives (self-hosting) for pretty much anything not requiring specialized hardware
Most AWS docs are over-engineered marketing designed to get you to pull in 8 other billable services just to use the one you wanted in the first place.
Knowing how to decipher their docs and navigate support is a resume-worthy skill.
The thing is beyond like top 10 AWS services(ec2, s3, sqs, aurora and few more) this is how most of AWS is. It’s just stuff thrown at the wall to see if it sticks.
I wouldn’t be surprised if median AWS service does less than 100k in annual revenue
8/10 times, you don't need these 3rd party providers. Yes, someone is going to tell me all about the SSOs, SCIMs, Audit Logs etc etc but the point is that 8/10 applications are simple enough to build their own Auth. The rest, go for these services. I never understood the appeal of these 3rd party providers who can hold you hostage just for your users to login ? In 2026 ? I don't get it. May be I am dumb.
I noticed this week that the menu button on LinkedIn posts now lets you choose "Seems like AI slop" as an option. How bold of them to call it what it is...
Hacker News is ready for something besides "flag," because it's very frustrating to have so much LLM-generated noise clogging up /classic.
Yes, Cognito is a mess. But why can't you write about it in your own voice? Hope the clicks and SEO juice was worth insulting your readers' limited time, Josh Karamuth.
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.
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.
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.
I hated the idea of self hosting keycloak, learning how to terraform every single inch of it. But I worked at a startup that had a fucking weird investor who paid me, and would pay AWS, but wouldn't pay Okta (or any other 3rd party).
So given the choice between Cognito (easy right? It's a managed service!) and Keycloak (a large, complex security Swiss Army knife) should have been a no-brainer in favour of Cognito. But we absolutely hated it. I think it's one of the worst AWS services I've used.
Keycloak is only hard because security is hard. The terraform provider is amazing, worked remarkably well. We never had a single hitch, and I could spin up new tenants in seconds, or deploy Keycloak to other regions in a few minutes.
Personally, I just hate the idea of running that type of thing in production unless it's my full time job (and it wasn't) and I have other team members who also knowit backwards. But for a sufficiently well staffed org that feels like moving this expertise inhouse and dumping a paid auth service, Keycloak really is amazingly good.
Now that I've moved on to another job, my time spent in the belly of Keycloak wasn't wasted either. I can help our security team figure out auth issues blindfolded (ie: without access to their Okta admin interface, and in fact having never seen one)
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 no worse than 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.
... or those who don't know about constant-time functions, the difference between sha1 and argon2, etc. etc.
I had to fix such things several times in corporate internet-facing systems. A generalist engineer can do this just fine, if they're aware of the state of the art, but there's nothing ensuring that they actually do. The compliance tickboxes were of no help here either.
I both hate and love Cognito. Hate it for its unnecessary complexity, love it for providing auth at bargain bin prices. I review Auth0 contracts frequently and that is daylight robbery/extortion, a poster child for vendor-lock-in. I had hopes for clerk.dev, but unfortunately the auth business optimizes for deep lock-in + steadily escalating prices.
After working through a few transitions to/from Auth0 that is something I never ever want to do again at scale.
This is so weird because AI should be good at updating the docs.
And yet, I often think this about things which still suck even though AI is good at them. Like why is Siri so bad still. Why do so many basic things in windows 11 not work, like folder search? Why does Altium or anything by Xilinx always have outdated docs that refer to menus that dont exist anymore?
AI actually is decently good at updating docs. But the kinds of problems that are being described in this thread, like documentation that varies wildly in tone and target audience or that describes different versions of the same service, or where how to do something is covered across multiple semi-overlapping pieces of documentation (some of which are up to date and some of which are not) are all a real strong indicator of inadequate centralized ownership of the docs. And the AI ain't gonna update the docs if nobody tells it to. (And AI still requires a great deal of micro-management to be used effectively in docs authorship.)
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.
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).
> just hook into the Auth library you use (library, not service).
I think this is a fundamental misunderstanding of how this stuff works. You can't "just use a library". Your identity server is a service, open source or not and you have to align to how they do things.
I'm talking about handling the OAuth token exchange and what not. Your identity server doesn't need to be a separate service, it can be integrated into your backend. At the end of the day it's responsible for making sure client claiming to be X is X. I really don't think this is rocket science.
I've set up email/password, email magic links, SMS 2FA codes, OAuth, and it's never been this magical, mystical thing these "auth providers" want to pretend it is.
Yes, you need to wire up endpoint for you to feed data to the library (tokens), and provide ways to refresh tokens, etc but that's all just wiring up and I don't think that's really that hard (even before LLMs).
I just cannot fathom handing over as much control and third-party auth providers require you to.
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).
> 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...
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.
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.
> 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.
GCP is famous for having two ways to do everything: the undocumented way and the deprecated way. You choose.
I've been making this joke about Google (big tech in general) for years.
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.
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?
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.
I haven't used much GCP, I'm just being snarky.
Yes, gcp has volumes of available accurate documentation, but it's almost entirely incomprehensible and bizarrely undiscoverable by search
If only they had a parent company that specialised in search
Yep, if someone thinks AWS docs are rough, wait till they try Azure docs!
The Azure documentation is learn.microsoft.com, I'm not sure why you mean there's nothing (or only videos). Just saying.
Documentation clearly following Conway's law: shipping the org chart.
No one gets promoted for writing good docs.
They get promoted for fucking with them. We were in the middle of a big fight with Microsoft support over a product defect. They literally updated the product docs in realtime and revised the sizing guidance for the product to be about 5% under our sizing. It was too specific a number to be a coincidence.
We were at war with them, so the team was capturing the documentation and timestamping it. They gaslit us to run the clock so the product would slide outside of mainstream support.
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.
Fun times.
>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.
I guess that's what they trained Opus 5 on
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 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 for accessing S3, where my app uses KMS keys to sign the url. Sounds simple and obvious but for the entire history of Cloudfront and KMS it was not! It is not documented to work, nor could I find any explicit AWS documentation saying that it wouldn't work either. And there's a just bunch of anecdotal reports (blogs, github issues) that it doesn't work. But very recently (April I think) Cloudfront and KMS, for the first time ever, both started to support the same key algo/size. So it's now possible, but I stumbled on it, and have never seen a recipe for using them together. So AI doesn't know about it either!
I was finally able to stop managing and rotating TLS key pairs, replicating private keys globally to my apps.
So: who really reads those little boring announcements, and connects the dots? Seemingly, not even AWS themselves!
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.
I reckon the documentation was fine. Together with AWS reinvent videos and together with well architected. Except for IAM that was a huuuge struggle.
Sadly no companies at all are qilling to use anything else than Azure nowadays.
They’re gaming search for attention.
Being useful to a human is incidental side effect.
> 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.
I also would never use cognito again.
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
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.
> How many paid auth providers let you export user password hashes so that you can seamlessly migrate to another vendor, if you want to?
Clerk is surely one of the biggest and allows you to do this.
Pretty much all of them do. Auth0 will be annoying about it but even they will do it
I'm struggling to think of one that's refused in my experience.
Ory let's you do this I believe.
Yup for the Ory managed service (Ory Network) you can export all data through the admin API including hashed passwords. Of course when self-hosting Ory you have full control over the database as well.
Disclosure: working for Ory.
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.
Yes it’s cheap. But you get what you pay for.
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.
Disclosure: working for Ory.
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.
Yea I went through this as well - when I tested it, they also required you be on a paid plan to even be able to get the export, which is kinda crazy. I work at an auth company now (Clerk) and this experience drove our current approach, which is that you can instantly export all your user data through a button in the dashboard. Maybe it's not as "sticky", but I think respecting your users when they want to get their data or migrate off is way more important.
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.
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...
Auth0 already was acquired.
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.
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.
When evaluating a third-party service like Cognito in this case or a mail provider, I either require that it uses an open standard for access like SMTP or the interface that I need to use is small enough that I can wrap it in my own layer of indirection so I can easily mock it and swap it out later. Most of the time I never switch it. But god damn, does it feel good to know that I can move if I need to and I'm not locked in.
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.
Keycloak and Ory are the only providers I would actually endorse, and I've used just about all of them.
Cognito is a pain, but it mostly works once you get through their horrible docs.
Auth0 is a vendor locked PoS with a very aggressive sales team.
Could you expand on why Auth0 is a PoS? I've never really liked it, but auth is not my area. Of course, our company uses it...
Lots of really thorny gotcha's relating to their proprietary triggers that aren't documented anywhere.
You will end up having to talk to their devs and inevitably get answers that are some flavor of "pay for enterprise, but you can't test to see if it actually solves your problem".
It can also be very expensive and messy to setup developer environments since there is not self-hosted option.
I haven't used it in a professional setting since the Okta acquisition, but I can't imagine it has gotten any better.
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.
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.
One big pro about cognito.. can't beat the price.
They added new enterprise features, free ride is over if you want any improvements made to the service in the last 8 years.
I used to be an architect with a bag of pro certifications for the world's largest AWS services provider/developer/reseller (we even did a lot of work for Amazon.com themselves). I gave it up a few years ago when it became clear that for most people, moving OUT of the cloud was a far better move than moving IN.
In a lot of ways, I really love AWS, but most of the high-value services are increasingly flaky and questionably supported, and nearly all of them have (often not very obvious) lock-in barbs.
For a while, cloud native development actually made sense. But as Cloud services have converged to become just big Kubernetes providers with API sprinkles (whose syntax is often more vinegary than sugary), there is less and less value there.
Add to that that almost no companies really need a huge cloud-based system to run their businesses, and that $500-2500 computers literally outstrip the performance of supercomputers from around the turn of the century in every respect, and there is less and less real need for cloud services...
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.
The documentation complaint is true of many, maybe all, AWS services: they discuss multiple generations, address multiple target audiences, and range wildly in currency and relevance, from marketing material to technical deep dives, all intermixed.
Cognito itself is a very AWS tradeoff. It's delightfully inexpensive. It quite effectively protects one of the most relentlessly attacked parts of any web service. It supports workflows essential as you scale, like SAML federation ("single sign on/SSO"). It basically works, day in and day out.
But OMG, the sharp edges! It has sharp edges to spare, even compared to other AWS services, for which sharp edges and exposed corners are just par for the course.
Then you try to go the next step, e.g. add multi-region disaster recovery and failover. That seemingly straightforward requirement to scale up is "left as an exercise for the reader."
Cognito has all the virtues of a utility service, including the developer experience.
In a previous greenfield project (pre-LLM) I considered using Cognito since I was all-in on AWS (Lambda, DynamoDB, ApiG, Route53, S3, SQS/SNS, and the list goes on...) but after reading through the docs I wanted to pull my hair out. What I thought was going to be a time-saving measure turned into a quagmire. Even with my level of "lock in" I was not willing to hand over auth and so I rolled my own (and it worked fine).
Nowadays I can't imagine using a 3rd-party for something like auth (or many other things) due to lock-in and also just always needing to conform to their way of doing things.
Apologies for the non-sequitur but 2 days ago I saw FreshDesk had deleted my account (free plan) that I had been using (sparingly, <50 tickets total if I had to guess) for 3+ years. No email, no notice, just deleted my account and broke the sites that I had integrated their feedback widget into. I reached out to see what was going on and they pretty much told me I had to upgrade if I wanted my account back.
Now 1-2 years ago I would have considered paying. In fact I would have considered paying IF they had contacted me to say "pay up or we will delete" but the fact they deleted it without any contact meant FreshDesk was dead to me. I started, for all of 1 minute, to consider the alternatives before I fired up Claude and in <2hrs I had a full replacement for all the parts of FreshDesk I was using (basic ticketing, emails, statuses, file upload).
The build-vs-buy decision has completely flipped for me. I have a hard time thinking of paying for something my platform depends on, especially auth, when it's so easy to build it now.
Side Note: that "all-in" AWS project? Yeah, with Claude's help I'm off 90% of the AWS's services and while it's still hosted there I can move to any VPS if I want now that I've removed my dependencies on AWS-specific concepts. It's been glorious and it has the side effect of meaning my local dev more-closely matches the deployed code since there isn't AWS-magic I have to fake anymore.
Auth is a bit of a different beast when it comes to the build vs buy debate though. A competent auth provider has the infrastructure (and necessary data) to deflect against DDoS attacks, bots, etc.
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
One greenfield project I worked on our AWS rep specifically told us to avoid Cognito and go towards auth0 or whatever else.
On another project people didn't get this advice and we spent a two weeks working around the limitations to scrap it eventually.
I had the same learnings with cognito when using it for a product we built.
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.
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.
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
I did some work for a sizable org who were pursuing a migration from their in-house auth to cognito. They originally scoped it at two months, and it ended up taking them six to roll it out.
Then they figured out that their cost projection was actually off by an order of magnitude. And also kept getting bitten by peripheral systems newly getting out of sync.
And so then, they embarked upon the journey to roll it all back...
> That’s not an upgrade. That’s a hostage situation.
yeppppppp. Pangram says: 100% AI. Why do we even bother.
Hey, I thought "rawdogging" sounded pretty authentic. Does claude say rawdogging now too?
for Auth - why don't people go with trusted solutions that work without hiccups.
if you want hosted setups - FusionAuth, Stytch etc.
if you work in a mainstream language/framework - some excellent libraries eg in ruby authentication-zero, in js - BetterAuth, Django-all-auth.
for AWS as well - use their solutions where you don't need to read a lot of docs.
AWS is good at operations, i.e. running something like S3 at massive scale. Or SQS, ddb, etc. High surface area for distributed systems, but low surface area for user experience.
Once you add in product decision making, like how to make the dev experience good on something with alot of user flows (like cognito), the products are shit.
LDAP, or...
Linux/BSD as the identity/runtime layer, SSH is the protocol boundary, and your web backend is the command gateway.
Yeah good example of this also with the agent stuff they are pushing now, documentation can read to be sales-like and then as you start using it stuff starts to fall apart. At this point there are better open source alternatives (self-hosting) for pretty much anything not requiring specialized hardware
Most AWS docs are over-engineered marketing designed to get you to pull in 8 other billable services just to use the one you wanted in the first place.
Knowing how to decipher their docs and navigate support is a resume-worthy skill.
The thing is beyond like top 10 AWS services(ec2, s3, sqs, aurora and few more) this is how most of AWS is. It’s just stuff thrown at the wall to see if it sticks.
I wouldn’t be surprised if median AWS service does less than 100k in annual revenue
I am going to be that guy.
8/10 times, you don't need these 3rd party providers. Yes, someone is going to tell me all about the SSOs, SCIMs, Audit Logs etc etc but the point is that 8/10 applications are simple enough to build their own Auth. The rest, go for these services. I never understood the appeal of these 3rd party providers who can hold you hostage just for your users to login ? In 2026 ? I don't get it. May be I am dumb.
I agree, even if you don't want to roll your own Keycloak is good enough for just about everyone.
I like Keycloak a lot but didn't select them because I cannot use my own frontend framework.
You should take a look at their client adapters, thats what I use.
https://www.keycloak.org/securing-apps/javascript-adapter
how are these claude written blogs consistently making front page?
Most readers are agents, and they upvote their fellow countryman....
I noticed this week that the menu button on LinkedIn posts now lets you choose "Seems like AI slop" as an option. How bold of them to call it what it is...
Hacker News is ready for something besides "flag," because it's very frustrating to have so much LLM-generated noise clogging up /classic.
Yes, Cognito is a mess. But why can't you write about it in your own voice? Hope the clicks and SEO juice was worth insulting your readers' limited time, Josh Karamuth.
HN users are just as susceptible to slop as anyone else, despite their belief that they are smarter than the average Redditor.
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.
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.
Ory has a really good config and deployment story, Keycloak is more feature rich.
Personally I choose Keycloak, but Ory is not a bad choice at all if you are willing to do more upfront work.
WorkOS is incredible, even if you don't need any of the "enterprise" features and you're building an entirely B2C app.
Used all 3, I would go with Ory.
Just out of interest, what makes you choose Ory over Keycloak/WorkOs?
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.
AWS is mental health hazard, has been for many years.
Friends don't let friends use AWS Cognito.
For those that don't use AWS Cognito, what's the next best alternative these days? (Don't say Auth0 either)
Big fan of Keycloak personally, but I'm also deep in the Quarkus/JVM ecosystem and Quarkus makes deving against Keycloak extremely easy.
Asking as someone who's only every rolled his own or used Cognito: What's the problem with Auth0?
Ory stack has been working very well for us.
I hated the idea of self hosting keycloak, learning how to terraform every single inch of it. But I worked at a startup that had a fucking weird investor who paid me, and would pay AWS, but wouldn't pay Okta (or any other 3rd party).
So given the choice between Cognito (easy right? It's a managed service!) and Keycloak (a large, complex security Swiss Army knife) should have been a no-brainer in favour of Cognito. But we absolutely hated it. I think it's one of the worst AWS services I've used.
Keycloak is only hard because security is hard. The terraform provider is amazing, worked remarkably well. We never had a single hitch, and I could spin up new tenants in seconds, or deploy Keycloak to other regions in a few minutes.
Personally, I just hate the idea of running that type of thing in production unless it's my full time job (and it wasn't) and I have other team members who also knowit backwards. But for a sufficiently well staffed org that feels like moving this expertise inhouse and dumping a paid auth service, Keycloak really is amazingly good.
Now that I've moved on to another job, my time spent in the belly of Keycloak wasn't wasted either. I can help our security team figure out auth issues blindfolded (ie: without access to their Okta admin interface, and in fact having never seen one)
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 no worse than 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 caution against using DynamoDB when just starting out. It’s too easy to paint yourself into a corner.
Nobody is ever going to convince me AWS isn’t hostile to users as a filter
Like how scammers put in typos
It’s not for users it’s for people who think 1/4 of the traffic a raspberry pi could handle is scale. Or don’t know what a server is.
... or those who don't know about constant-time functions, the difference between sha1 and argon2, etc. etc. I had to fix such things several times in corporate internet-facing systems. A generalist engineer can do this just fine, if they're aware of the state of the art, but there's nothing ensuring that they actually do. The compliance tickboxes were of no help here either.
I both hate and love Cognito. Hate it for its unnecessary complexity, love it for providing auth at bargain bin prices. I review Auth0 contracts frequently and that is daylight robbery/extortion, a poster child for vendor-lock-in. I had hopes for clerk.dev, but unfortunately the auth business optimizes for deep lock-in + steadily escalating prices.
After working through a few transitions to/from Auth0 that is something I never ever want to do again at scale.
cannot believe in the age of AI, they still couldn't fix the docs issue.
This is so weird because AI should be good at updating the docs.
And yet, I often think this about things which still suck even though AI is good at them. Like why is Siri so bad still. Why do so many basic things in windows 11 not work, like folder search? Why does Altium or anything by Xilinx always have outdated docs that refer to menus that dont exist anymore?
AI actually is decently good at updating docs. But the kinds of problems that are being described in this thread, like documentation that varies wildly in tone and target audience or that describes different versions of the same service, or where how to do something is covered across multiple semi-overlapping pieces of documentation (some of which are up to date and some of which are not) are all a real strong indicator of inadequate centralized ownership of the docs. And the AI ain't gonna update the docs if nobody tells it to. (And AI still requires a great deal of micro-management to be used effectively in docs authorship.)
Why not keycloak?
Why use any AWS for a startup?
Why use AWS for any size company?
This reads like, and is confirmed by Pangram to be, 100% AI slop
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.
"That’s not an upgrade. That’s a hostage situation."
hah that quote makes my day.
I'll be sad when AI gets advanced enough that we can't immediately detect it in writing. For now the slop remains pretty easy to spot.
If you can't tell, does it matter?
just swear and use slurs, that way we know you are human
[dead]
[dead]
[flagged]
[flagged]
[dead]
[dead]
IMHO not rolling your own auth is asking for stuff like this to happen.
I believe the opposite of this statement to be true
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).
> just hook into the Auth library you use (library, not service).
I think this is a fundamental misunderstanding of how this stuff works. You can't "just use a library". Your identity server is a service, open source or not and you have to align to how they do things.
I'm talking about handling the OAuth token exchange and what not. Your identity server doesn't need to be a separate service, it can be integrated into your backend. At the end of the day it's responsible for making sure client claiming to be X is X. I really don't think this is rocket science.
I've set up email/password, email magic links, SMS 2FA codes, OAuth, and it's never been this magical, mystical thing these "auth providers" want to pretend it is.
Yes, you need to wire up endpoint for you to feed data to the library (tokens), and provide ways to refresh tokens, etc but that's all just wiring up and I don't think that's really that hard (even before LLMs).
I just cannot fathom handing over as much control and third-party auth providers require you to.
This is a terrible take, and to anyone reading this please don't roll your own auth, you will regret it.
There are lots of good options out there that enterprisey abominations.
>> and even rawdogged a custom JWT system ...
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.
"sucks" was originally a homophobic pejorative. Languages evolve, sometimes very rapidly.
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).
The article it's written by Reddit trained AI what do you expect?
do you realize this is really annoying and don't care or actually think you're being helpful?