Re: Past Proposals for HTTP Auth Logout

Hi Yutaka,

> Currently I am implementing/specifying a log-out feature as a part of
> our Mutual authentication protocol proposal: more detail for our
> proposal are at
>   https://tools.ietf.org/html/draft-oiwa-http-mutualauth-05 and
>   https://www.rcis.aist.go.jp/special/MutualAuth/ .

Cool.  While I like Digest a lot better than basic auth, it still
leaves much to be desired, particularly in all of it's optional
features and ambiguous RFC. =\  I think it's definitely a good idea to
provide more HTTP auth options.

> Because the proposal aims to replace both Basic/Digest AND form-based
> authentication in a future, we needed to design a useful log-out
> feature, which are required to support many currently-cookie-based web
> applications.

Yes, I think an explicit log out function is a necessity.  I am still
leaning toward an explicit response to effect that, as I guess you do.

> Regarding log-out implementation on HTTP authentication,
> discarding a username/password pair and all session keys (e.g. nonces
> in Digest) associated to that pair should basically be fine.
> However, I thought there are a few features needed to be added to current
> HTTP protocol, to support various services currently implemented in web
> applications.  I added such a few features as a part of our proposal.

I have not yet had time to grok your new protocol, so I appologize if
I don't understand how you plan on implementing this...

> I currently propose it as a part of our Mutual auth. protocol, but if
> people are interested, it can be reorganized as a generic extension to
> HTTP 1.1.  Please look and tell me your impression if any.  We already
> have a patch to Mozilla Firefox, based on our proposal.

I think it would *definitely* be beneficial to users and to the
adoption of your protocol if there were a more explicit log out
function for all HTTP auth.

Right now, developers don't bother with HTTP auth in most cases
because they can't customize the login forms and there's the
impression that there's no way to log out.  There are hacks out there
to achieve login with XMLHTTPRequests and this will hopefully be made
easier as the interface is standardized.  (I plan on describing this
in detail in a future paper.)

So logouts are still outstanding.  There are also AJAX hacks to make
this work in some browsers, but it's not a great solution.  Yes, you
could ask all browsers to change behavior with 401s to make this
possible, but application developers will likely find it confusing to
send a 401 with a login form in one case, and send a 401 with a
"you've successfully logged out" page in another case.  Introducing a
more explicit HTTP code for this will make it easier for browsers to
differentiate and also for developers.

In any case, I think if the user interface problem were solved for
Basic and Digest, then transitioning to Mutual or any other more
advanced auth scheme would be much easier.

> What I added in the proposal are
> 
>   - a facility for client to request log-out.
> 
>   - a response header for server to request client to force log-out.
>     (logout-timeout field, specified in Sections 4.6 and 7.3 of our proposal)
>     it can either be timeout-based or be immediate.
> 
>   - a response header for server to request client to be redirected when
>     user requests a log-out (location-when-logout field, Sec. 7.2).
>     This will be especially useful when the user requests log-out on
>     a page served to a POST request.


Ok, interesting.  Sounds very featureful, which is good in the long
run.  For my interests, I would want something bloody simple in it's
most basic form with room for extensibility.

My initial thought was to define a new 2XX response code which
required one or more WWW-Authenticate headers (or a header type that
has a similar form to WWW-Authenticate).  The header would define, at
a minimum, the authentication protocol and the realm.  It could have
additional protocol-specific elements, such as crypto blobs (to
integrity protect the log out), or even elements which define which
specific domains should be removed from the protection space (in the
case of Digest and perhaps Mutual, this would allow remaining
protection spaces to remain in the session).

However, it probably doesn't make sense to define a new 2XX code, now
that I think about it more.  The same could be achieved by a simple
header in a 200 OK response.  The key here, is to use a 2XX of some
kind so that if a browser doesn't support the new header, it'll just
ignore it and developers can use AJAX hacks in the body to achieve the
same end in popular browsers during the transition period. 

Would something like this work with your new protocol?  Also, what is
the goal of the location-when-logout design?  Could the body of a 200
response as I propose not achieve a similar goal?  It's just that it
seems confusing to mix 2XX/3XX/4XX semantics by having a redirect
instruction potentially appear in non-3XX response types.

Thanks!
tim

Received on Friday, 8 January 2010 18:00:09 UTC