tptacek 2 days ago

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.

  • 63stack a day ago

    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.

    • ljm a day ago

      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.

    • matt7340 a day ago

      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.

      • grinich a day ago

        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

    • giancarlostoro a day ago

      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.

    • apitman a day ago

      Sadly enough it is actually a win win.

  • lordofgibbons 2 days ago

    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.

    • unscaled 2 days ago

      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.

  • foota 2 days ago

    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.

  • rafram 2 days ago

    Is a hashed password really “hazmat data”?

    • evantbyrne a day ago

      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.

    • tptacek 2 days ago

      Extremely yes.

      • 63stack a day ago

        Can you elaborate?

      • littlestymaar a day ago

        Why? What's the threat model here?

        • akerl_ a day ago

          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.

          • littlestymaar 12 hours ago

            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.

            • akerl_ 7 hours ago

              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

heavensteeth 2 days 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.

  • sedatk 2 days ago

    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.

mleonhard a day ago

    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.

  • cmackenzie1 a day ago

    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!

    • LorenzoGood a day ago

      Big enum?

      • cmackenzie1 6 hours ago

        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.

        • LorenzoGood 4 hours ago

          What about providing a plugin registration macro that generates an enum that can be provided to the library.

chrisweekly a day ago

I wonder if the name's similarity to "Tauri" (Rust-based alternative to Electron) will lead to confusion.

jayy-lmao a day ago

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

alok-g 2 days ago

What similar libraries exist for other languages? (I could not find myself.) Thanks.