[HN Gopher] Show HN: Torii - a framework agnostic authentication...
___________________________________________________________________
Show HN: Torii - a framework agnostic authentication library for
Rust
Author : cmackenzie1
Score : 75 points
Date : 2025-02-28 23:16 UTC (23 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| croisillon wrote:
| not related: A map of torii around the world (6 days ago - 49
| comments) https://news.ycombinator.com/item?id=43141966
| tptacek wrote:
| 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.
| lordofgibbons wrote:
| 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 wrote:
| 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.
| apitman wrote:
| 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...
| foota wrote:
| 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 wrote:
| Is a hashed password really "hazmat data"?
| tptacek wrote:
| Extremely yes.
| 63stack wrote:
| Can you elaborate?
| littlestymaar wrote:
| Why? What's the threat model here?
| akerl_ wrote:
| 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.
| evantbyrne wrote:
| 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.
| 63stack wrote:
| 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.
| apitman wrote:
| Sadly enough it is actually a win win.
| matt7340 wrote:
| 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 wrote:
| 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
| ljm wrote:
| 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.
| giancarlostoro wrote:
| 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.
| heavensteeth wrote:
| 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 wrote:
| 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.
| alok-g wrote:
| What similar libraries exist for other languages? (I could not
| find myself.) Thanks.
| cmackenzie1 wrote:
| 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.
| alok-g wrote:
| Thanks.
|
| Sounds like there's not much like this for Java or C#.
| chrisweekly wrote:
| I wonder if the name's similarity to "Tauri" (Rust-based
| alternative to Electron) will lead to confusion.
| mleonhard wrote:
| 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 wrote:
| 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!
| jayy-lmao wrote:
| 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
___________________________________________________________________
(page generated 2025-03-01 23:02 UTC)