Hacker News Reader

Comment by wutwutwat | Hacker News Reader

> I also find it difficult to rationalize third-party dependencies these days

Your home grown auth code doesn’t have the minds and the scrutiny of security experts like the go-to third party auth lib everyone uses does, nor does it have the free pen testing, security fixes, maintenance, optimizations, refactors, ever collaborative maintainers, or corporate sponsorships.

Auth is a solved problem by minds much smarter than my own. I’m glad to outsource things like that to third party deps.

View on HN

Well, it also doesn't have LDAP dependencies in the Log stack to cause bunch of those issues in the first place.

And while I kind of agree with you on principle, I've also seen way too many shoddy OSS libraries from "experts" that I had to rewrite to really make it a no-brainer statement.

Just like OP, I'm leaning against shoveling in dependencies if I can help it as I age.

The issue I take with this stance is that people reading will put auth in the "too scary to implement" bucket mentally, and think it's fine to pay the Auth0 tax on every single project, even one with a few users.

This is a great resource to learn how to write it yourself, and things to take into consideration: https://lucia-auth.com/

IMO, this is one thing to implement carefully if need be (vs avoid altogether, as is the case of cryptography).

I should have clarified, I wasn't talking about third party auth SaaS providers, I was talking about auth libraries you'd use in your codebase.

I also left "auth" ambiguous and didn't specify "authentication" or "authorization" because my original comment applies to both imo.

> Auth is a solved problem by minds much smarter than my own.

Is it? It seems like all the outsourced auth has lots and lots and lots of problems, issues, etc. along with being remarkably expensive.

I'm not saying I, personally, can do better, but it seems like auth is far from a solved problem. Especially since it seems like the difficult part of "auth" is actually "customer support" rather than any technical issue.

(I would argue that the lack of an open-source "Auth in a Box" seems to also argue that auth is far from "solved".)

I was talking about third party libraries (library code), not providers (okta)

The evil in the details:

Spring Security is complex and brittle, I have seen a push to use underlying libraries e.g. nimbus in real-life projects.

There are many open source "auth in a box" projects that you can self-host, such as Ory (https://github.com/ory/), Zitadel, Keycloak, and many other small projects. They all have small differences but for small to mid scale projects its definitely manageable.

I would go beyond auth to areas where there historically have been security bugs. Parsing JPEG files for instance, I can write a parser and can probably choose a modern safe language to avoid many classes of bugs, but a popular open source library is more likely to have been fuzzed by dozens of techniques from multiple companies and universities. The code is more resilient because it has been out there to be experimented on in public.

All of those auth abstractions do a lot more than what I want. And because of that, they are far more complicated. And they can involve so much abstraction that you don't even know exactly how your own system works. And the lack of understanding can lead to worse practices.

Probably because auth abstractions are so complicated is why developers started thinking auth is hard when all it was doing was putting a uuidv4 in a session_id cookie.

Like writing SQL without an ORM, developers have been psyop'ed into thinking things are so hard that they shouldn't even try.

> Auth is a solved problem

It is solved until you have to integrate with third party home grown implementations and providers that implement the specs except for a little bit of behavior that is not in the spec.

I see you've worked with oauth2 providers, my friend. Welcome to the circus :)

Is auth that difficult? The truly difficult problem is cryptography and that's the code you really don't want to write. But most authentication schemes are well-known. No need to import a library, and if you do, you should be prepared to vendor it in.

> most authentication schemes are well-known

so why maintain your own implementation of the scheme/spec when a community already does, as well as handles the vulns as they pop up and generally has more eyes looking (and fixing) issues?

Here's how I look at it; Trust my own NIH implementation of a spec and hope a user reports a vuln instead of it going undisclosed/unnoticed in the wild for years, or use a community lib that is always being scrutinized and vetted and has security professionals involved. It's a no brainer for me.

Honestly I’m not convinced it is a solved problem.

I have been trying to get my head around OAuth, zero trust, Fido, SAML et al - and I am not sure I get it.

It’s not that say “JWT tokens might be dangerous” it’s how to hang it all together in a sane manner.

For example I was listening to Security Cryptography Whatever podcast and one of the guests (Chrome dev?) said obviously don’t trust everything that comes down an established TLS connection but verify / auth each request.

That’s a pretty tall order and seems to nullify quite a lot of established frameworks

But realistically I think a lot of frameworks and standards serve different needs than “smallish number high value clients”

It all depends on the attack surface/vectors. In some cases, YAGNI. It all comes down to what is more likely to be your biggest PITA: the steady time expense of updating all your deps to accomdate that patched auth lib OR the cost of dealing with whatever breech you're likely to incur is.

> Auth is a solved problem by minds much smarter than my own.

Imagine a doctor making such statement about their field of work. Do you have a degree?

Doctors refer patients to specialists all the time.

Yes: to specialists that have typically another 5 years of formal education on top. They do not refer patients for relatively trivial topics covered in the first year of a bachelor‘s degree.

Ah, so the cryptography involved in authentication schemes is a first year CS trivial task. Hashing, salting, optimization, defending against side-channel attacks, looking for backdoors introduced by state actors, developing standards used by the strongest militaries on the planet that protects literally enough nuclear weapons to destroy all life on the planet, that's old news by week 3 of the course at any community college. The folks who went overboard with those Phds in cryptography or became specialists in elite OpSec or post-quantum cryptography really did waste their time and money, and someone should tell the CIA they don't need to go hunting for the best cryptography hackers on the planet, just grab a year one CS brogrammer and they can totally make sure all is secure in the ToR network.

Tell you what. I'll never become a specialist if you never become a doctor. I'd rather you not refuse to admit that there are better doctors for a task than you if my health is in your hands.

This is exactly what a responsible doctor is supposed to do.

Reply on news.ycombinator.com