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.
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.
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.
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
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.
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.
https://github.com/lastlogin-net/obligator?tab=readme-ov-fil...
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.
At best, stored passwords are something you always get right and are value neutral to you. And everything below that is toxic.
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.
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
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?
let plugin = state
.plugin_manager
.get_plugin::<OAuthPlugin<SqliteStorage, SqliteStorage>>("github")
.unwrap();
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.
If you have any suggestions for making it better, let me know!
Great work, I’m sure this will save numerous dev-hours
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.
Sounds like there's not much like this for Java or C#.
1: https://docs.oracle.com/en/java/javase/22/security/java-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.