Subject: [http-auth] User directed logout

From: Jason Greene <[email-masked]>
Date: Mon, 6 Oct 2014 10:46:30 -0500

I noticed a statement in reviewing the new mutual auth RFC:

"If a user explicitly requests to log out (via user interfaces),
 the client MUST forget the user's password, go to step 5 and
 reload the current resource without an authentication header."

This reminded me of a long standing issue with browser based authentication, in that brittle and browser specific hacks are required to get them to stop caching credentials in the case that a web application wishes to provide a “log out” feature.

Has there been any consideration to resolving this in auth protocols (e.g. a user directed termination indicator of some sort)? I think this could be a good thing. Otherwise I don’t see how the above text could actually be implemented?

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Yoav Nir <[email-masked]>
Date: Mon, 6 Oct 2014 18:59:26 +0300

> Has there been any consideration to resolving this in auth protocols (e.g. a user directed termination indicator of some sort)? I think this could be a good thing. Otherwise I don’t see how the abo…

Hi, Jason.

When web applications offer a log-out, there is no way for them to tell the browser, because the browser’s ability to cache previously-entered passwords is at a different layer than the HTML or javascript code that creates the web form. It may be possible to extend Javascript with an API to do this, but that would be something for W3C to do. 

MutualAuth is at the HTTP layer. A browser can’t support it without code changes. So the RFC can tell the browser vendor to delete the cache in certain cases. If the browser password cache is an external application or extension, it might not work.

Yoav

---

From: Michael Sweet <[email-masked]>
Date: Mon, 06 Oct 2014 12:12:32 -0400

FWIW, there are ways to prevent the password strings from being cached by the browser in the first place (autocomplete attribute, Javascript, etc.) and some OS's and browsers offer guest/privacy modes that will discard everything after the window/session is closed.  Not perfect, but I suspect any solution will need to be defined at multiple levels to cover all usage.

> On Oct 6, 2014, at 11:59 AM, Yoav Nir <[email-masked]> wrote:
> 
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Jason Greene <[email-masked]>
Date: Mon, 6 Oct 2014 11:12:41 -0500

> When web applications offer a log-out, there is no way for them to tell the browser, because the browser’s ability to cache previously-entered passwords is at a different layer than the HTML or jav…

That’s true for a client side logout mechanism, but it can also be server side in a similar a manner that applications can already control cookies and web sessions. A server vendor could provide an auth log-out call which would then cause the server, in an http response to include some credential discard indicator. The client side JS/html portion would then just perform an application specific POST to the server side code which calls the method.

This would also allow for certain server-side forced logout scenarios, such as a requirement that a user always re-enter their credentials after a set idle timeframe.

> MutualAuth is at the HTTP layer. A browser can’t support it without code changes. So the RFC can tell the browser vendor to delete the cache in certain cases. If the browser password cache is an ex…

I think, but am not totally sure my above reply would address this.

---

From: Jason Greene <[email-masked]>
Date: Mon, 6 Oct 2014 11:28:49 -0500

The issue referring to is a different scenario. I am referring to browser directed HTTP authentication (e.g. Basic & Digest today, mutual auth tomorrow), whereas you are referring to application authentication via form posting. So in this case there is no form, but a browser controlled user password pop-up. These aggressively cache passwords, to the extent that even a digest renogitiaton (due to nonce invalidation) still reuses the cached password. Aside from the hacks (which typically involve temporary switching of realms, or the evil user@fake-pass URL trick), the only reliable mechanism is to require the user exit the browser. However, as you know, browsers are very long running these days (especially on a mobile device), and asking users to quit them is just not a practical solution.

---

From: Jason Greene <[email-masked]>
Date: Mon, 6 Oct 2014 11:31:41 -0500

On Oct 6, 2014, at 11:28 AM, Jason Greene <[email-masked]> wrote:
 These aggressively cache passwords, to the extent that even a digest renogitiaton (due to nonce invalidation) still reuses the cached password. 

I should have qualified this to be “some browsers”. Not all are consistent.

—
Jason T. Greene

---

From: Michael Sweet <[email-masked]>
Date: Mon, 06 Oct 2014 12:31:51 -0400

Perhaps we could add a "no-cache" parameter for the HTTP Basic and HTTP Digest updates?  That would only work for newer browsers, but at least it allows the server to indicate it doesn't want the client to cache the username and password for future challenges?

> On Oct 6, 2014, at 12:28 PM, Jason Greene <[email-masked]> wrote:
>

---

From: Tim <[email-masked]>
Date: Mon, 6 Oct 2014 09:31:57 -0700

> This would also allow for certain server-side forced logout scenarios, such as a requirement that a user always re-enter their credentials after a set idle timeframe.

FWIW, I think this is exactly what is needed in all HTTP auth methods.
This is how cookie-based authentication systems currently handle log
outs, so web developers won't see a major shift in their approach if
they can simply add some indication to a response header that clients
should forget session credentials. 

tim

---

From: Yoav Nir <[email-masked]>
Date: Mon, 6 Oct 2014 20:40:04 +0300

> Perhaps we could add a "no-cache" parameter for the HTTP Basic and HTTP Digest updates?  That would only work for newer browsers, but at least it allows the server to indicate it doesn't want the c…

If websites started doing that, I’d get a password manager browser extension that overrode this.

---

From: Tim <[email-masked]>
Date: Mon, 6 Oct 2014 10:44:53 -0700

> If websites started doing that, I’d get a password manager browser extension that overrode this. 

I agree this doesn't seem as useful to me either. Nor does it address
the major outstanding issue in HTTP auth, being the lack of explicit
log out.

tim

---

From: Cameron Jones <[email-masked]>
Date: Thu, 9 Oct 2014 10:55:37 +0100

On Mon, Oct 6, 2014 at 4:59 PM, Yoav Nir <[email-masked]> wrote:

> > This reminded me of a long standing issue with browser based
> authentication, in that brittle and browser specific hacks are required to
> get them to stop caching credentials in the case that a web application
> wishes to provide a “log out” feature.
> >
> > Has there been any consideration to resolving this in auth protocols
> (e.g. a user directed termination indicator of some sort)? I think this
> could be a good thing. Otherwise I don’t see how the above text could
> actually be implemented?
> >
>
> Hi, Jason.
>
> When web applications offer a log-out, there is no way for them to tell
> the browser, because the browser’s ability to cache previously-entered
> passwords is at a different layer than the HTML or javascript code that
> creates the web form. It may be possible to extend Javascript with an API
> to do this, but that would be something for W3C to do.
>
>
The Form HTTP Extensions specification defines some new controls within
HTML for a high level hook into providing logout functionality over HTTP
authentication. There is also frequent discussions about providing a
Javascript API but an actual specification is still pending.

http://www.w3.org/TR/form-http-extensions/

Thanks,
Cameron Jones

> MutualAuth is at the HTTP layer. A browser can’t support it without code
> changes. So the RFC can tell the browser vendor to delete the cache in
> certain cases. If the browser password cache is an external application or
> extension, it might not work.
>
> Yoav
>
>

---

From: Jason Greene <[email-masked]>
Date: Tue, 14 Oct 2014 15:03:31 -0500

On Oct 9, 2014, at 4:55 AM, Cameron Jones <[email-masked]> wrote:
> The Form HTTP Extensions specification defines some new controls within HTML for a high level hook into providing logout functionality over HTTP authentication. There is also frequent discussions about providing a Javascript API but an actual specification is still pending.
> 

Interesting. I am hopeful this will be ratified, and that vendors will opt to include it. There really should be a JS API for XHR as well, although I suppose the form will be well enough since it can be hidden and submitted on behalf of the user.