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

Share and Enjoy:
  • del.icio.us
  • DZone
  • Facebook
  • Reddit
  • StumbleUpon
  • Digg
  • Simpy
  • Technorati

{ 8 comments to read ... please submit one more! }

  1. There are a bunch of authentication/RBAC frameworks out there, and integrating them with various MVC frameworks (e.g. via filters) shouldn’t be too difficult.

    I think the main reason mainstream frameworks stay away from this, is there are as many possible security models as there are programmers in the world – that is, the number of possible permutations and variations are almost infinite, and there is no accepted/minimum “standard” for security-models as such.

    In my experience, security requirements vary greatly from one application to the next, and what I’ve seen of frameworks that do ship with a security model (such as Yii), these tend to be either far too complex and loaded with concepts that don’t (necessarily) fit the business model, or blatantly simple and not really useful; or they just don’t fit for some reason.

    I challenge you to come up with a simple, universally useful (framework independent) security-model that people would actually use – prove me wrong, please! Until then, I will continue to build security-models as needed…

  2. I am not suggesting that there is a universal 100% across the board covers everything model. I do suggest that almost all apps have a basic need for identifying a user, allowing users to self-register (or to connect up to something like LDAP/AD to verify), some basic mechanism to create users, turn their accounts on and off, allow users to change basic profile info (or at least email) and ‘lost password’ – these concepts make up a HUGE majority of the situations that force most people to roll their own.

    What I also find is that some frameworks come with some classes, but no screens or any UI – you’re left to roll that as well.

    I posit that if there were some moderate user/security functionality built in to a framework, most people would use those basics, and there would be some extensions built on. As it stands, because you have to roll your own, people *think up* more customized functionality than they actually need.

    WordPress comes with some basic functionality re: users – there are some roles, you can add some, but the basics work for a lot of the out of the box needs. As people need more, they add more via plugins (and other plugins also add their own extra security requirements). But ‘out of the box’ it’s providing some basics.

    Astute readers will argue that ‘wordpress isn’t a framework!’, and I’d counter that it’s become a standard framework for a lot more applications than you’d probably care to acknowledge, precisely because it provides a core of baseline functionality for a whole lot of stuff.

  3. Please note that the Solar framework shipped with authentication, role, and access controls.

    http://solarphp.com/manual/user.auth-process

    I expect we will port this to Aura at some point in the future.

  4. Thanks for the info Paul :)

  5. Interesting perspective Michael. I think you are right about wordpress (you can throw Drupal into that category as well).

    I find it interesting that the monolithic frameworks put everything else in the box yet punt on authentication/admin. Seems like the target audience would appreciate this sort of thing. I wish I had time to write more about why I’ve completely lost interest in pretty much every one of the available monolithic frameworks (tl;dr: they spend valuable time bike-shedding on all the easy stuff and punt on the stuff that would provide the most value — not to mention, that type of development is less sustainable anyhow).

    That said, I would like to point out that Django (Python) ships with authentication and an administration system: https://docs.djangoproject.com/en/1.4/topics/auth/

    Also, in your update section, you wrote:

    “One thought is that no one wants to be even remotely possible…”

    Could you have meant to say?:

    “One thought is that no one wants to be even remotely **responsible**…”

    Thanks for writing this up.

  6. Thanks – Django, yes, I knew I was forgetting something. And yes, I’d throw Drupal, Joomla, probably Umbraco and other “CMS”-ish projects in there as well.

    And yes, they all punt on the hard stuff. Another one: ZF not having any default or recommended Model infrastructure because “everyone’s model needs are different” – I’ve heard that as a justification from several developers (albeit, not core ZF devs, so I can’t vouch for that as the real reason).

    Thanks for your thoughts Wil!

{ 1 Pingbacks/Trackbacks }

  1. Episode 108: New Ruby, Regex and my Framework Security Rant(tm) | PHP Podcasts

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">



0.21503806114197