Re: Past Proposals for HTTP Auth Logout

Hi Bruno,

> There was a similar discussion on rest-discuss a few days ago:
> http://tech.groups.yahoo.com/group/rest-discuss/message/14856

Thanks for the link, I'll take a read through.

> Alan Dean was looking for something that would work with Digest
> auth. I just don't see that being possible with the current
> XMLHttpRequest specifications (since you can't specify Digest
> premptively).

Well, actually in HTTP authentication, user agents are supposed to
request the resource without credentials initially.  Once prompted
with a 401, they then know what HTTP authentication mechanisms are
supported by the server and can choose which to use.  There is
actually no other way to implement Digest authentication without this
initial 2-step process since the browser needs the Nonce and other
information to get started.

In the application I put together (using tidbits of information from
many of the same sources mentioned in that thread and elsehwere),
browsers do indeed request the resource first without credentials,
receive a 401, then turn around and try the credentials given in the
open() method.

As far a specifying which HTTP auth scheme to use in JavaScript, no
there isn't a way to do this.  Ultimately, the JavaScript in this
approach must be supplied by the same server doing the authentication
(due to same-origin restrictions on XMLHttpRequest), so it's really a
moot point.  That same server advertises the available methods in the
next request.

I definitely see the desire to restrict the authentication method due
to man-in-the-middle attacks, but specifying the auth scheme in
JavaScript buys you nothing here.  Someone can just MitM the
JavaScript.  As mentioned in my paper, the only way around this kind
of downgrade attack is for browsers to know a priori which scheme is
supported.  Since this isn't possible with current protocols, I
suggested browsers caching which sites support stronger auth schemes
when they are first accessed and then requiring those auth schemes be
used in the future.  See the paper for details.


> > I generally wish there was a "WWW-Authenticate: Form" mechanism (or
> > some form of security token, or cookie like this IETF draft), but for
> > this to be effective, it would need to be implemented in major
> > browsers.

I don't think this is a good idea, personally.  It seems to be
directed at making badly designed authentication standardized.


> >I've also tried to suggest a "WWW-Authenticate: Transport" (or
> >some other name), mainly for TLS client certificate
> >authentication, but it didn't go very far (I'd need to improve the
> >idea).

You should look at the Mutual authentication scheme proposed by Yutaka
OIWA (mentioned in this aging thread).


> It seems there's a discussion in the HTML5 WG about accessing
> cookies from HTML, but I haven't followed it. I'm not sure how good
> an idea this is. Such mechanism could enable AJAX forms to set the
> authentication cookie/token perhaps.
> I'd prefer a solution that has a clearly separated authentication
> scheme (rather than using 'Cookies' at all, have a separate
> authentication token store in the browser, capable of login/logout),
> but the 'WWW-Authenticate: Cookie' scheme seems it could be a
> reasonable compromise.

I don't think any of this complexity is necessary.  With one very
simple, backward compatible change to HTTP, the ability to do a log
out, one already has all of the pieces to do very powerful and secure
forms-based session management.  That is, if the XMLHttpRequest
proposed standard is adopted as-is with respect to 401 handling.  This
then opens up the possibility using dozens of possible HTTP
authentication schemes which are much better than digest auth.

> I'm not sure being able to log out from Basic/Digest auth is an HTTP
> issue; it sounds more like a issue of browser interface and/or
> interaction between the webpage and the browser's handling of
> authentication: HTML 5 might be a good place to discuss this.

Take a look at the reasoning presented in the rest of this thread.  
In summary: 

HTTP authentication allows one to log in, but why doesn't allow one to
log out?  Application developers need to be able to drive the log out
process, they can't rely on browser user interfaces.  (There's nothing
wrong with browser-driven log outs, but we need application-driven
ones as well).

One could place log outs into HTML or JavaScript standards, but why
the asymmetry?  What about user agents that don't support JavaScript?
What about automated user agents that don't deal with HTML content at
all?  HTTP-driven log out makes sense in more situations than the
other approaches.


> I do think, however, that there's room for new "WWW-Authenticate"
> schemes: something for 'Cookies' (or generic auth token) and
> something for 'Transport' (to indicate that the authentication is
> done out of the HTTP scope, e.g. via the underlying SSL/TLS stack).

But like I said, this is just standardizing bad practices.  See the
paper.  By inventing new WWW-Authenticate methods which just continue
to use cookies, you through out several good HTTP auth schemes and
have to reinvent the wheel based on limited primitives (cookies).

Instead, let us fix the user interface problems with existing auth
schemes and suddenly we give application developers a whole lot more
options.  XMLHttpRequest objects can let us get there, for the most
part.

thanks for the feedback,
tim

Received on Thursday, 25 February 2010 19:05:39 UTC