Why do no almost no web frameworks come with any authentication/authorization functionality?

This is likely a controversial stance to take, and I’ll very likely get bashed as “no idea what I’m talking about” by people much cleverer than me.  With that said…

Why do almost no web frameworks provide any default authentication/authorization functionality, with default examples of best practices for common use cases.  The standard response I’ve gotten for years was/is “well, everyone’s needs for authentication are different”.

No, they are not. A (very?) large majority of web applications (which is what most web frameworks are used to build), require some form of user login and authorization management, and often self-registration, dealing with lost passwords, etc.

Yet somehow, everyone’s essentially forced in to writing their own user login and management from scratch. This leads to potentially loads of security holes from people writing insecure code.

So many frameworks promote their routing and database layers, configuration management, etc.; those are all things that one could argue people might need to function “differently” – in many cases, the default code is configurable enough to handle many edge cases. In rare cases when the stock code can’t handle things, you can override it with custom code.

But with authentication/authorization, everyone is left to fend for themselves.  Every.  Single.  Time.  And they *often* get it wrong (sensitive info in a cookie, unencrypted passwords, etc).

Put another way, when left to fend for themselves, developers need to learn a lot of concepts.  Every decision point is a point that can be made wrong (or poorly).  Making a poor decision about your CSS colors or URL structure or JavaScript helper library might be painful or annoying, but will likely not have any major repercussions.  Making a poor decision about authentication can be devastating.   Yet, somehow, this is one of the prime areas in the web framework world where users are not given anything out of the box (in most cases, at least) and are left to ‘educate themselves’ (with quite a lot of bad, wrong or outdated information floating around).

If you’re not going to ship some basic authentication/authorization functionality with the rationale that not everyone’s needs are 100% the same, perhaps you should stop shipping routing, forms management, database libraries and more – after all, someone might want to do it their own way.  Not everyone’s queries are the same, don’t you know.

I titled this post “almost”, because I’ve got a hunch there may be a few that I don’t know about.  With that said, what web frameworks do you know of which ship with authorization/authentication out of the box?  My own experiences indicate:

In the PHP world, it looks like Symfony2 ships with an ACL component, and the recommended ‘default bundle’ distributions ships with Authorization and Authentication components out of the box.   Zend Framework ships with an ACL component as well, but in both cases (ZF and Symfony) there is no default way of allowing users to register/login/reset passwords, etc.  FWIW, the Symfony approach of distributing recommended bundles of packages which (from what I can tell) could be updated independently if and when need be might be the best middle ground I’ve seen so far.  “Decoupled but packaged”.

The Rails community seems to (nearly) universally rely on Devise, but it’s not shipped by default, and many people end up ‘rolling their own’ (probably very often with bad and possibly even hard to spot flaws).

Grails users often rely on the Spring Security plugin, but again, not a default plugin.  To its credit, there is a basic user/role management screen with searching, account disabling, and other maintenance functionality, and the basic system allows for user login and ‘lost password’ pretty much out of the box (self register is a bit more work).    But again, not shipped with the base, and people may be tempted to roll their own (although a default ORM means people are far less likely to be susceptible to SQL injection vs building SQL by hand).

ASP.NET ships with a membership system (though it’s been a long time – my memory may be out of date), with web controls for user login, registration, lost password, etc.  Whether it’s necessarily the ‘best’ security approach is not really the point here – it’s a standard that is provided, and more than likely has prevented people from (re)writing code in an insecure manner.

What am I missing?

UPDATE: One thought is that no one wants to be even remotely possible for providing out of the box security because they’re afraid they’ll be a target for a lawsuit.  I suspect that’s not really a factor, but perhaps it is in some cases?

I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Web Developer Freelancing Handbook

Leave a Reply