Subject: OT re HTTP auth disassocation of credentials

From: Adrien de Croy <[email-masked]>
Date: Mon, 19 Sep 2011 16:18:34 +1200

Hi all

I know this is outside the WG charter, but I thought it could be topical 
in terms of recent discussions on authentication.

One of the failings (IMHO) of the HTTP auth as implemented by most 
browsers, is the impossibility of implementing a logout function in a 
web site which uses HTTP auth.

Since client browsers cache credentials (for obvious reasons), they will 
re-present cached creds for each new page if there's ever a 401 returned.

This means once you use HTTP authentication to establish creds with a 
site, you can't disassociate your browser from these creds without 
shutting it down.  In most cases, this involves shutting down every 
instance of your browser.

Compared with your typical website that uses cookie/session-based login, 
this seems like a fairly glaring omission.

So, what if there were some status code, or response header that could 
be used to tell a browser to clear the cached credentials for that 
site?  Then you could put up a link on your web page, call it logout, 
and when the user clicks it, you send back that status or header.  Then 
the client unlearns the creds so that the next auth challenge from that 
site results in a login dialog in the client.

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 beta out now - http://www.wingate.com/getlatest/

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 19 Sep 2011 06:30:39 +0200

Hi Adrien,

> site results in a login dialog in the client.

I agree, I've missed this a number of times too. In fact, I noticed that
if you force the server to return 401 when presented the valid credentials,
most browsers seem to forget the ones they used to cache. But this is
terribly dirty, as the user receives a new pop-up where he's tempted to
re-enter his credentials...

I think that the difficulty for browers is how to deal with multiple
parallel connections. If one of them returns "4XX logout" and others
still return 2xx or 3xx in response to some Authorization headers, it
may be confused. This probably means that the "4xx logout" should
cause an immediate flush of the cached credentials and that no window
of frame or connection may use a cached version of them. Maybe this is
already something simple for browsers, I don't know.

> Adrien

Best regards,
Willy

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 19 Sep 2011 08:37:00 +0200

On Sep 19, 2011, at 6:18 AM, Adrien de Croy wrote:

> 
> So, what if there were some status code, or response header that could be used to tell a browser to clear the cached credentials for that site?

FWIW I'd rather see browsers put a logout-button right in the browser GUI. The button could simply cause the browser to stop sending the credentials.

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 19 Sep 2011 15:34:08 +0200

On Sep 19, 2011, at 2:43 PM, Karl Dubost wrote:

> 
> Le 19 sept. 2011 à 02:37, Jan Algermissen a écrit :
> As much as I could see the benefit for it. I do not think this will fly for browser vendors. They are all currently trying to simplify the UI and minimize it.

... credentials could simply time out..

(Causing all users to set the timeout to 'never' in turn :-)

Jan

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 20 Sep 2011 09:28:23 +1200

I think it would me more useful if it could be controlled from the 
server.  Hence a status or header.

However, for browser vendors, since finding screen real-estate is such a 
problem, an approach could be taken similar to the one used to show that 
a sight is using TLS and to see certificate information.  E.g. a small 
icon showing that the request is authenticated, which could then give 
details of the method, and an option to log out.

Adrien

On 20/09/2011 12:43 a.m., Karl Dubost wrote:
> As much as I could see the benefit for it. I do not think this will fly for browser vendors. They are all currently trying to simplify the UI and minimize it. There is also the balance in between introducing a new UI feature with the number of times this (HTTP Auth) will be used. For example, Firefox removed the RSS icon (by default).
>
> PS: not advocating for any sides of the issue.
>

---

From: Karl Dubost <[email-masked]>
Date: Mon, 19 Sep 2011 08:43:38 -0400

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 20 Sep 2011 04:51:50 +0200

* Karl Dubost wrote:
>As much as I could see the benefit for it. I do not think this will fly
>for browser vendors. They are all currently trying to simplify the UI
>and minimize it. 

I have argued for such a feature without success since the 1990s, but at
the moment you have at least Mozilla working on putting the login/logout
gizmos into the browser user interface. I am not saying what they are
doing is any good, but they are doing something, and I doubt this taking
up screen space is regarded as much of a problem there.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Eric Lawrence <[email-masked]>
Date: Wed, 21 Sep 2011 15:29:43 +0000

FWIW, IE6+ offers a script-accessible method for clearing the session-cached credentials, and both Chrome and Firefox have bugs filed to offer similar functionality. See the end of the post http://blogs.msdn.com/b/ieinternals/archive/2010/04/05/understanding-browser-session-lifetime.aspx

One interesting scenario Microsoft ran into here recently is that the new "Metro-style" version of our browser cannot be "closed" in the usual way (its lifetime is controlled automatically). We settled upon having the closure of the last tab (which simply replaces the old tab with a new default tab) clear the authentication cache and session cookies, even though the browser itself does not close.

-Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bjoern Hoehrmann
Sent: Tuesday, September 20, 2011 3:52 AM
To: Karl Dubost
Cc: HTTP Working Group
Subject: Re: OT re HTTP auth disassocation of credentials

>for browser vendors. They are all currently trying to simplify the UI 

I have argued for such a feature without success since the 1990s, but at the moment you have at least Mozilla working on putting the login/logout gizmos into the browser user interface. I am not saying what they are doing is any good, but they are doing something, and I doubt this taking up screen space is regarded as much of a problem there.
--
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Sep 2011 14:58:01 +0200

> One interesting scenario Microsoft ran into here recently is that the new "Metro-style" version of our browser cannot be "closed" in the usual way (its lifetime is controlled automatically). We set…

Interesting; thanks for the pointers.

It seems everybody agrees that something like this is needed, but most 
want something that is restricted to the current session.

Eric, Karl: you represent two browser vendors, maybe you could chat, and 
come up with a joint proposal?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Sep 2011 15:06:04 +0200

On 2011-09-19 06:30, Willy Tarreau wrote:
> ...
> ...

But that's not different from today with logging out from sites using 
cookie authentication, right?

Speccing a 4xx status code seems to be quite simple, but I'll assume 
most sites would be hesitant to use something for "logout" when there's 
no simple way to find out whether the UA understood it.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 25 Sep 2011 15:20:41 +0200

Hi Julian,

> cookie authentication, right?

I think it's slightly different because with a cookie, when the server
deletes it, it's not valid anymore. So even if the browser posts a few
requests with the recently deleted cookie, they will not be authenticated.
With user:passwd credentials, the logout is just an event at one point but
does not remove the credentials' validity. So the few possibly pending
requests which are sent with the credentials should not cause these
credentials to be used again afterwards. But I agree it's just a matter
of implementation.

> no simple way to find out whether the UA understood it.

That's a good point. In my experience, user:password auth was mostly
used on internal networks. The lack of logout feature is more a matter
of convenience than a real security issue because the population is
limited and clients are installed on machines that are more or less
associated to one user. So even if the UA ignores the 4xx, it's not
a bit deal.

There are also places where web developers waste a lot of time
connecting/disconnecting and constantly have to open/close the browser
because they're experimentating with different user profiles. I noticed
that with proxy auth too, where people validate URL filters, or have to
switch their profile. But here it should probably be a browser feature
and not a 4xx code.

Just my 2 cents,
Willy