Cognito and Auth0 are so popular because 1) somewhere in the past 5 years developers got bullied into believing that doing authentication is now hard, high risk, dangerous, hard to get right, and all kinds of scare words in the name of the security theater, and, 2) there are a lot of incompetent people who somehow don't understand that you should not put your database on the public internet without authentication.
Just outsource all of that to us, we will all take care of all that very hard work for you, really, just 5.99$/month at first, and when we inevitably get hacked, because actually it's us that have no fucking idea what security is, since we only understand security theater compliance language, you can point your fingers at us so you don't get fired, and we will wash our hands with some vague PR words. Win win.
I think auth in the way that b2b services require it is, at the bare minimum, awkward, and made more difficult when you step out of a language ecosystem where that problem has been solved extensively.
As you say though it’s not technically hard, it’s just a massive fucking faff. OIDC, identity providers, oAuth2, SSO… and I would argue that solutions like Cognito complicate that setup far more than they should.
Plus, it’s an easy B2B money maker when so many businesses lock their SSO functionality behind a top-tier enterprise plan. So that’s the real reason for making auth harder than it is. If it was about security it would be a basic feature.
Sure, but you are forgetting about compliance and adopting the same standards org wise across thousands of projects spanning hundreds of teams and jurisdictions, and separate industry standards across. Thats what adopting something like Auth0 is for.
All true, but glosses over a lot of nuance and wide variety of contexts, particularly B2B.
We’re likely going to switch to Cognito because maintaining OIDC auth has been a pretty big cost for a small company. IdP configurability in particular is painful both technically and in customer support.
One downside to Cognito/etc though is while they’ll handle the tech side (Okta notwithstanding), it’s still up to you to troubleshoot and configure and integrate correctly. Lots of opportunities to “solve” the security risks, but hurt customer and user experience in the process.
I'm the founder of WorkOS and we solve this problem for developers, primarily focusing on the challenges around enterprise SAML, SCIM, complex RBAC, fine-grained authorization, and more.
They will charge you an arm and a leg, and to top it off, Okta (owned by Auth0) was hacked multiple times in the past couple of years.
These hosted solutions are also very tricky (not sure if even possible) if you need to ship your software for companies to host in their own cloud environment.
Auth0 is owned by Okta, not the other way around, and it used to be an independent company. I don't particularly like the way Auth0 works (like only supporting JWT for access tokens), but as far as I know they have not been impacted by the Okta hacks.
I don't think startups who went with Auth0 or AWS Cogito are necessarily "doing it wrong". It's a question of resources and focus. Writing your own authentication solution requires some expertise (especially if you're basing it on OAuth), but there are mature frameworks like Passport (for Node.js/Express) and Devise (for Ruby on Rails). You still need to be careful when setting up these things (there are so many authentication options for Passport.js some of them are bound to be bad), but it's better than rolling your own. Unfortunately, I'm not aware of anything at this maturity level for Rust.
Side note: Note everything that's out there and mature is easy to use correctly. Keycloak is probably more of an Okta than Auth0, in that it is focused on the Enterprise world. It's extremely flexible, and I'm sure you can build secure and performant setups based on Keycloak - it's just that I've never seen one, and I've seen quite a few Keycloak setups.
I guess there's maybe an argument for this out there for sufficiently large paranoid companies that would rather own something in house, but would also rather collaborate on an auth system than build one from scratch (something like if Google wanted to adopt a new auth system for some reason).
The other use case (other than people/companies with NIH), might be government or other similarly high risk systems, where they'd rather have a dedicated system rather than a sort of unknown risk of someone else running it (not that I think it would necessarily be more secure in practice).
That said, I feel like on premises deployment of something like auth0 might be closer to what those people would want, rather than something relatively untested.
Right? If a company can't be trusted to do password hashing, then they definitely shouldn't be trusted with PII. With that said, I think it's the SSO and broader ecosystem that orgs are paying vendors for.
Perhaps a little petty, but I dislike that about half of the readme, at the beginning no less, is an AI generated image. I dislike images in readmes in general, and this one doesn't even provide any value.
I don't care about images in README's in general. It could represent developer's love for their project or set the mood for the rest of the document. But, AI image generation models are notoriously known for having been trained with works of artists without their permission. Many of those models are ethically problematic. They also almost always look poorly done as in this example. I don't doubt dev's intentions, but I agree that this looks bad.
I don't know that sovereignty is what a lot of apps want for this kind of hazmat data, which is why Cognito and Auth0 are so popular.
Cognito and Auth0 are so popular because 1) somewhere in the past 5 years developers got bullied into believing that doing authentication is now hard, high risk, dangerous, hard to get right, and all kinds of scare words in the name of the security theater, and, 2) there are a lot of incompetent people who somehow don't understand that you should not put your database on the public internet without authentication.
Just outsource all of that to us, we will all take care of all that very hard work for you, really, just 5.99$/month at first, and when we inevitably get hacked, because actually it's us that have no fucking idea what security is, since we only understand security theater compliance language, you can point your fingers at us so you don't get fired, and we will wash our hands with some vague PR words. Win win.
I think auth in the way that b2b services require it is, at the bare minimum, awkward, and made more difficult when you step out of a language ecosystem where that problem has been solved extensively.
As you say though it’s not technically hard, it’s just a massive fucking faff. OIDC, identity providers, oAuth2, SSO… and I would argue that solutions like Cognito complicate that setup far more than they should.
Plus, it’s an easy B2B money maker when so many businesses lock their SSO functionality behind a top-tier enterprise plan. So that’s the real reason for making auth harder than it is. If it was about security it would be a basic feature.
Sure, but you are forgetting about compliance and adopting the same standards org wise across thousands of projects spanning hundreds of teams and jurisdictions, and separate industry standards across. Thats what adopting something like Auth0 is for.
All true, but glosses over a lot of nuance and wide variety of contexts, particularly B2B.
We’re likely going to switch to Cognito because maintaining OIDC auth has been a pretty big cost for a small company. IdP configurability in particular is painful both technically and in customer support.
One downside to Cognito/etc though is while they’ll handle the tech side (Okta notwithstanding), it’s still up to you to troubleshoot and configure and integrate correctly. Lots of opportunities to “solve” the security risks, but hurt customer and user experience in the process.
I'm the founder of WorkOS and we solve this problem for developers, primarily focusing on the challenges around enterprise SAML, SCIM, complex RBAC, fine-grained authorization, and more.
We build the Admin Portal for IdP configuration: https://workos.com/admin-portal
WorkOS actually launched on HN about 5 years ago[0] and today it's used by OpenAI, Cursor, Perplexity, and hundreds of other companies.
Feel free to email me if I can help: mg@workos.com
[0] https://news.ycombinator.com/item?id=22607402
Sadly enough it is actually a win win.
They will charge you an arm and a leg, and to top it off, Okta (owned by Auth0) was hacked multiple times in the past couple of years.
These hosted solutions are also very tricky (not sure if even possible) if you need to ship your software for companies to host in their own cloud environment.
Auth0 is owned by Okta, not the other way around, and it used to be an independent company. I don't particularly like the way Auth0 works (like only supporting JWT for access tokens), but as far as I know they have not been impacted by the Okta hacks.
I don't think startups who went with Auth0 or AWS Cogito are necessarily "doing it wrong". It's a question of resources and focus. Writing your own authentication solution requires some expertise (especially if you're basing it on OAuth), but there are mature frameworks like Passport (for Node.js/Express) and Devise (for Ruby on Rails). You still need to be careful when setting up these things (there are so many authentication options for Passport.js some of them are bound to be bad), but it's better than rolling your own. Unfortunately, I'm not aware of anything at this maturity level for Rust.
Side note: Note everything that's out there and mature is easy to use correctly. Keycloak is probably more of an Okta than Auth0, in that it is focused on the Enterprise world. It's extremely flexible, and I'm sure you can build secure and performant setups based on Keycloak - it's just that I've never seen one, and I've seen quite a few Keycloak setups.
To replace Auth0/Okta you really need something like Passport.js and something like Keycloak. I maintain a decent list of Keycloak alternatives here:
https://github.com/lastlogin-net/obligator?tab=readme-ov-fil...
I guess there's maybe an argument for this out there for sufficiently large paranoid companies that would rather own something in house, but would also rather collaborate on an auth system than build one from scratch (something like if Google wanted to adopt a new auth system for some reason).
The other use case (other than people/companies with NIH), might be government or other similarly high risk systems, where they'd rather have a dedicated system rather than a sort of unknown risk of someone else running it (not that I think it would necessarily be more secure in practice).
That said, I feel like on premises deployment of something like auth0 might be closer to what those people would want, rather than something relatively untested.
Is a hashed password really “hazmat data”?
Right? If a company can't be trusted to do password hashing, then they definitely shouldn't be trusted with PII. With that said, I think it's the SSO and broader ecosystem that orgs are paying vendors for.
Extremely yes.
Why? What's the threat model here?
Can you elaborate?
not related: A map of torii around the world (6 days ago - 49 comments) https://news.ycombinator.com/item?id=43141966
I wonder if the name's similarity to "Tauri" (Rust-based alternative to Electron) will lead to confusion.
Perhaps a little petty, but I dislike that about half of the readme, at the beginning no less, is an AI generated image. I dislike images in readmes in general, and this one doesn't even provide any value.
I don't care about images in README's in general. It could represent developer's love for their project or set the mood for the rest of the document. But, AI image generation models are notoriously known for having been trained with works of artists without their permission. Many of those models are ethically problematic. They also almost always look poorly done as in this example. I don't doubt dev's intentions, but I agree that this looks bad.
What similar libraries exist for other languages? (I could not find myself.) Thanks.
JavaScript definitely has a few such OpenAuthJS, Better-Auth, and Next-Auth.
PHP Laravel, Ruby on Rails, Python Django, Elixir Phoenix all have some ways of doing this, but are usually baked into the framework.
Others usually end up as a standalone service like Keycloak, Authelia and more.
[dead]
[dead]