[thelist] Cookies and Session state for Authentication

[Andrew Clover]

Mike Pouncy <pouncy_1 at hotmail.com> wrote:

> I am trying to build an authenication system that works for the
> largest possible group of users/browsers

HTTP Basic Authentication (triggered by the 401 response code and 
WWW-Authenticate header) is a required part of the HTTP spec and is 
supported by absolutely all browsers.

If Basic Authentication meets your needs it is definitely the best way 
to do auth - that's what it was designed for. Using cookies/sessions 
instead is a hack which is sometimes used to get around the limitations 
of Basic Auth (and just as often used because the authors just don't 
know about Basic Auth).

Limitations are:

   - the username/password is sent by the browser unencrypted.
     HTTP Digest Authentication gets around this but is not widely
     supported; if security is a requirement then encrypting the
     entire session (including username/password) using SSL is the
     best plan.

   - Basic Auth cannot be controlled from JavaScript. In a way this
     is a benefit for security as the login details are not vulnerable
     to theft through cross-site-scripting in the same way cookies are.
     However it means you can't manually log the user out or present
     a customised login page (you always get the browser's own auth
     prompt).

   - cross-server support can be tricky. In IIS you have to turn off
     all authentication methods except 'anonymous access', and remove
     custom error pages for 401 errors, to prevent IIS from getting in
     your way. (NB: I don't know if this is still the case for ASP.NET.
     You may also be able to use one of many ISAPI authentication filters
     to do the task for you.) In Apache you have to recompile with a
     flag set for it to pass auth information to CGI scripts.

It is possible to use a cookie-based auth scheme with basic auth as 
backup, but it's a bit of work.

-- 
Andrew Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/