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