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.
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.
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.
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.
Passwords are data that, once you've built a system that requires you store them, must be kept forever, with basically zero tolerance for loss or unavailability (so you have to make them continuously available to systems that validate user authentication), but also have zero tolerance for exposure. And it's a type of data that has no profit in it. You can't use it to improve UX or target ads or anything else of value.
At best, stored passwords are something you always get right and are value neutral to you. And everything below that is toxic.
While I don't disagree with anything you wrote in particular, nothing in your comment above answers the original question “why are hashed password hazardous material”.
My understanding was that if properly hashed, then the hashed passwords should have no value whatsoever (it should be indistinguishably from random noise and should not be reversible by any means).
The fact that tptacek (who is very well known for his competence in security and cryptography) says otherwise is intriguing me deeply but your response doesn't answer the question.
Properly stored nuclear material is safe as well. But it’s still hazardous material because if the storage or handling are imperfect, they are harmful.
Passwords are the same, except we’re constantly finding new attacks and weaknesses.
As some examples:
1. When a new attacks is found against a hash construction so all the password stored based on that are now more vulnerable
2. When it turns out your auth server is logging passwords in plaintext so it doesn’t help that your DB is storing them properly hashed.
3. When your auth call isn’t properly validating hashed passwords so attackers can either bypass the correct flow or intuit things about the password
2. and 3. have again nothing to do with the question. Plaintext passwords are obviously unsafe material, but that's not the point of the question.
Nuclear material that leaks its containment is bad no matter what, how is a hashed password leaking a bad thing is the entire question and you're only addressing it in 1. but I don't find that convincing. When was the last time a practical attack was found on a hashing scheme that wasn't already obsolete 15 years ago?
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.
let plugin = state
.plugin_manager
.get_plugin::<OAuthPlugin<SqliteStorage, SqliteStorage>>("github")
.unwrap();
What are the reasons for using a string to identify the plugin?
This pattern has some downsides: reduced code clarity (navigating to the plugin is hard), and it changes a class of errors from compile-time to run-time.
I’ve gone back and forth on using TypeId or named plugins using a string. Mainly switched to the named variant to support each oauth provider lookup by name.
If you have any suggestions for making it better, let me know!
If the library wasn't open for extension, an enum could work. With the currently model, users can write their own plugins, bring their own storage provider, or even write an email consumer that reacts to events from the EventBus - all without needing to upstream their changes to torii and torii-core.
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.
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
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.
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?
Passwords are data that, once you've built a system that requires you store them, must be kept forever, with basically zero tolerance for loss or unavailability (so you have to make them continuously available to systems that validate user authentication), but also have zero tolerance for exposure. And it's a type of data that has no profit in it. You can't use it to improve UX or target ads or anything else of value.
At best, stored passwords are something you always get right and are value neutral to you. And everything below that is toxic.
While I don't disagree with anything you wrote in particular, nothing in your comment above answers the original question “why are hashed password hazardous material”.
My understanding was that if properly hashed, then the hashed passwords should have no value whatsoever (it should be indistinguishably from random noise and should not be reversible by any means).
The fact that tptacek (who is very well known for his competence in security and cryptography) says otherwise is intriguing me deeply but your response doesn't answer the question.
Properly stored nuclear material is safe as well. But it’s still hazardous material because if the storage or handling are imperfect, they are harmful.
Passwords are the same, except we’re constantly finding new attacks and weaknesses.
As some examples:
1. When a new attacks is found against a hash construction so all the password stored based on that are now more vulnerable
2. When it turns out your auth server is logging passwords in plaintext so it doesn’t help that your DB is storing them properly hashed.
3. When your auth call isn’t properly validating hashed passwords so attackers can either bypass the correct flow or intuit things about the password
2. and 3. have again nothing to do with the question. Plaintext passwords are obviously unsafe material, but that's not the point of the question.
Nuclear material that leaks its containment is bad no matter what, how is a hashed password leaking a bad thing is the entire question and you're only addressing it in 1. but I don't find that convincing. When was the last time a practical attack was found on a hashing scheme that wasn't already obsolete 15 years ago?
Can you elaborate?
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.
not related: A map of torii around the world (6 days ago - 49 comments) https://news.ycombinator.com/item?id=43141966
This pattern has some downsides: reduced code clarity (navigating to the plugin is hard), and it changes a class of errors from compile-time to run-time.
I’ve gone back and forth on using TypeId or named plugins using a string. Mainly switched to the named variant to support each oauth provider lookup by name.
If you have any suggestions for making it better, let me know!
Big enum?
If the library wasn't open for extension, an enum could work. With the currently model, users can write their own plugins, bring their own storage provider, or even write an email consumer that reacts to events from the EventBus - all without needing to upstream their changes to torii and torii-core.
What about providing a plugin registration macro that generates an enum that can be provided to the library.
So it’s not open for extension?
I wonder if the name's similarity to "Tauri" (Rust-based alternative to Electron) will lead to confusion.
About a week ago I was thinking about how much something like this is needed in Rust. Especially something web-framework and DB agnostic.
Great work, I’m sure this will save numerous dev-hours
Is it possible to develop custom oauth/openid plugins?
If you are looking to add another provider, one can do so here: https://github.com/cmackenzie1/torii-rs/tree/main/torii-auth...
If you want change the plugin logic completely, you can implement the Plugin trait and register the plugin with the plugin manager: https://github.com/cmackenzie1/torii-rs/blob/main/torii-core...
Doing the latter, you can also bring your own storage provider.
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.
Thanks.
Sounds like there's not much like this for Java or C#.
I think the most similar you'd find for Java are Shiro [0], Java Authentication and Authorization Service (JAAS) [1], and pac4j [2].
0: https://shiro.apache.org/
1: https://docs.oracle.com/en/java/javase/22/security/java-auth...
2: https://github.com/pac4j/pac4j
Thanks!
[dead]
[dead]