OT re HTTP auth disassocation of credentials

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

OT re HTTP auth disassocation of credentials

Adrien de Croy
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/


Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Willy Tarreau-3
Hi Adrien,

On Mon, Sep 19, 2011 at 04:18:34PM +1200, Adrien de Croy wrote:

> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Jan Algermissen-3
In reply to this post by Adrien de Croy

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


Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Karl Dubost-5

Le 19 sept. 2011 à 02:37, Jan Algermissen a écrit :
> 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.


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.

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


Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Jan Algermissen-3

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

>
> Le 19 sept. 2011 à 02:37, Jan Algermissen a écrit :
>> 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.
>
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Adrien de Croy
In reply to this post by Karl Dubost-5

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:
> Le 19 sept. 2011 à 02:37, Jan Algermissen a écrit :
>> 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.
>
> 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.
>

--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com


Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Bjoern Hoehrmann
In reply to this post by Karl Dubost-5
* 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:[hidden email] · 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/ 

Reply | Threaded
Open this post in threaded view
|

RE: OT re HTTP auth disassocation of credentials

Eric Lawrence-4
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: [hidden email] [mailto:[hidden email]] 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

* 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:[hidden email] · 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/ 


Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Julian Reschke
On 2011-09-21 17:29, Eric Lawrence wrote:
> 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

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

Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Julian Reschke
In reply to this post by Willy Tarreau-3
On 2011-09-19 06:30, Willy Tarreau wrote:

> ...
> 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.
> ...

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

Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Willy Tarreau-3
Hi Julian,

On Sun, Sep 25, 2011 at 03:06:04PM +0200, Julian Reschke wrote:

> >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.
> >...
>
> But that's not different from today with logging out from sites using
> 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.

> 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.

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


Reply | Threaded
Open this post in threaded view
|

Re: OT re HTTP auth disassocation of credentials

Yutaka OIWA
In reply to this post by Adrien de Croy
Dear all,
(added http-auth mailing list, responses preferred to this list)

recently some browser vendors are trying incorporating authentication
control with the browser's identity management mechanisms, and they
propose some HTML/JavaScript level extensions for it.
If you just need log-out feature, and if you can assume JavaScript support,
it may just work for you.  I think this trend may allow us a small icon
for authentication control, hopefully.

I am working from a bit different viewpoint, making HTTP authentication
support more features which is currently only available via Form-based
authentications, not limited to log-out control.
My proposal is currently in a part of my new HTTP authentication scheme
draft (draft-oiwa-http-mutualauth-09), and I am planning to make it
a separate draft in the next revision.

I put "pre-draft" on our Web page at

<https://www.rcis.aist.go.jp/special/MutualAuth/files/spec/draft-oiwa-http-auth-extension-pre00.4.txt>

(or < https://bit.ly/o3MDq4 > if line wrapping is nasty), and I will submit -00
draft possibly before the Taiwan meeting.
Again, it may be over-engineered for log-out only, but please have a look,
and if you're going to or wish to extend HTTP, it may serve for your needs.


On 09/20/11 06:28, Adrien de Croy wrote:

>
> 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:
>> Le 19 sept. 2011 à 02:37, Jan Algermissen a écrit :
>>> 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.
>>
>> 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.
>>
>