Ask HN: Why do almost no web frameworks have User auth as first class features? | Hacker News Reader

Ask HN: Why do almost no web frameworks have User auth as first class features?

14 pointsz9znz12 comments

Aside from Django, it seems most modern web frameworks provide little or no first-class user management or authN/Z features.

And although many frameworks have plugin or module extension capabilities, they still seem to lack "just works" user auth modules.

It is probably fair to say that a significant percentage of web applications are public facing and need user logins, accounts, and even profiles. This is not unlike how many web applications need persistent storage.

On the storage side, there are often clear and easy paths to databases and even cloud storage systems via plugins, and ORMs and such to simplify persistence.

But on the user auth side, the user of the framework is left with the task of integrating whatever external auth module. This is especially challenging when framework and external module versions shift, documentation and guides become out of date, and StackOverflow questions and answers become stale.

Why are we still reinventing this wheel so often?

Because there are a million different ways to do user authentication and authorization: LDAP, OAuth, cookies, federated logins, challenge-response devices, etc. A framework or library that tries to handle all these scenarios becomes abstract, hard to use, and not very powerful because it can only rely on the greatest common denominator. Django's auth is reasonable to get started, but probably not what you want to use for a production-ready website.

I have a different question: why do folks create a username+password based AuthN system on their own, instead of leveraging OAuth and letting someone else deal with the hard part of managing passwords, resets, etc. Or use a service like FusionAuth or Auth0, or Keycloak, et al? With Spring Boot + Spring Security's OAuth, all the AuthN work is done by the framework and I only need specify some configuration parameters (client IDs, secret, etc.) and I don't deal with anything else.

Now User Profiles as a first-class thing would be nice (I really do not want to reimplement managing profiles), but there's a lot more variation there. Though some out-of-the-box basics would be nice: name, nickname, time zone, preferred contact info, etc.

This sort of thing is why I only use Django. I'm on the Rust hype train and use it in several domains, but won't use it for websites for this reason. (Auth, migrations, email etc)

I've been using actix-web in Rust, works great for me. I would much rather have a few plug-ins (that are just as easy to configure as in Django) and work with a nice language than suffer through Python all day, Rust is just that much better in my view.

Django has it but most people end up building their own because it's highly domain specific.

The permissions framework is also so complicated that most projects don't use it.

At this point it's worth asking whether frameworks should even have built-in authentication when it's a simple matter of storing a session id in a cookie.

One word: liability. Auth is incredibly complex and there is no one size fits all solution, and when it inevitably fails for someone the cost is huge. Why take on that challenge and insane amount of risk when that’s not party of the core value proposition?

Don't most open source licenses have some form of "we are not responsible, use at your own risk" clause?

In any case, Django has provided this for years, and it probably is one of the reasons why a lot of apps get built on Django. I am really not a fan of Django, so I only use theirs if I'm paid to work on it. But if they can do it, why aren't the other popular frameworks giving that common need more attention?

I would argue that it is actually a value proposition and that it is one reason why Django has some of the marketshare it has.

Liability can also mean dealing with all the issues in supporting and maintaining the edge cases, not just legal woes.

It is probably much easier, from a maintenance standpoint, to simply allow other libraries take the mantle and just structure your project to play nice with middleware.

Much easier to just say “use package x for auth support.”

Phoenix has built in authentication, and it works.

https://hexdocs.pm/phoenix/mix_phx_gen_auth.html

It’s not default but Rails has Devise and it’s lovely.

Use ASP.Net Identity...

Next.js + NextAuth

Reply on news.ycombinator.com