[whatwg] Solving the login/logout problem in HTML

Asbjørn Ulsberg list at asbjorn.ulsberg.no
Wed Nov 26 12:55:49 PST 2008

On Tue, 25 Nov 2008 19:54:46 +0100, Julian Reschke <julian.reschke at gmx.de> wrote:

> thanks a lot for this proposal which seems to go into the right  
> direction.

Indeed. I think this is an area with an enormous potential for improvement and it's very encouraging to see so many great ideas about the issues involved and how to solve them.

> I didn't yet have time to look into this in detail, but it currently  
> seems to require the UA to still parse the HTML page. Wouldn't it be  
> better of the *headers* of the response (such as WW-Authenticate, Link,  
> ...) would contain sufficient information to perform the login without  
> having to do that; such as a URI to POST to, plus the parameter names  
> for user name and password?

I agree that more should happen on the HTTP level and with more control given to the web application. Considering the state of the next version of the HTTP specification(s), would it perhaps be a good idea to discuss this with the HTTP WG as well?

'WWW-Authenticate: HTML' or something similar is a step in the right direction. I don't see it as necessary to identify the form that does the authentication, though. Just as [1], I think that puts a burden on the user agent that really isn't necessary.

Web application developers pulls a lot of hair doing web form-based authentication already and are used to having control over just about every part of it. Taking that control and responsibility away at this point is only deterring, imho.

Instead, we should leave the control in the hands of the web application developers and force as little as possible on to the user agent developers. The way I see it, the following example should be enough to perform a successful authentication:

  [Request 1]

  GET /administration/ HTTP/1.1

  [Response 1]

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: HTML realm="Administration"

  <!DOCTYPE html>
    <form action="/login">
      <input name="username">
      <input type="password" name="password">
      <input type="submit">

  [Request 2]

  POST /login HTTP/1.1


  [Response 2]

  HTTP/1.1 302 Found
  Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm="Administration"
  Location: /administration/

  [Request 3]

  GET /administration/ HTTP/1.1
  Authorization: HTML QWxhZGRpbjpvcGVuIHNlc2FtZQ== realm="Administration"

  [Response 3]

  HTTP/1.1 200 OK

  <!DOCTYPE html>

The twist here is that it is up to the server to provide the authentication token and through the 'Authorization' header, give the client a way to authorize future requests. I append the "realm" parameter to the 'Authorization' header to give the server and client a way to control authorization and more importantly deauthenticate (e.g. logout) for different realms on the same web site.

Since more is up to the web application now, a deauthenticate works the following way:


  POST /logout HTTP/1.1


  HTTP/1.1 200 OK
  Authorization: HTML realm="Administration"

  <!DOCTYPE html>
    <h1>Good bye!</h1>

The empty token in the 'Authorization' header indicates that it should be forgotten for the given realm by the user agent and that future requests to resources within the same realm requires a reauthentication.

This suggestion overloads the 'Authorization' header quite a bit, but since we're inventing a new authentication scheme that the UA needs to understand anyway, and especially if we get the HTTP WG on board here, I think this can only give positive effects.

The alternative is to invent a new response header to serve the same purpose, but seeing as the request and response header -- if 'Authorization' is used -- are identical, a typical authentication by a browser supporting the "HTML" scheme is just to opaquely copy+pasting the entire 'Authorization' header from the request to the response.

[1] <http://www.w3.org/TR/NOTE-authentform>

Asbjørn Ulsberg         -=|=-          asbjorn at ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»

More information about the whatwg mailing list