Re: Authentication over HTTP

On 16/07/2013 10:04 p.m., Josh Howlett wrote:
>> That leaves only the application layer as the best suited for
>> authentication of identities (and/or resolution to attributes) that
>> the service needs for authorization (or even in the other direction).
>> This, I know, is a bit of a controversial opinion.  My proposal is
>> here: http://tools.ietf.org/html/draft-williams-http-rest-auth-01
>> (ah, I need to submit the WG version).
> I agree with this analysis. No single mechanism will meet every need. It
> is more important that HTTP has the agility to allow different mechanisms
> on a per-application basis, while maintaining a consistent presentation to
> users and application developers (as Nico's proposal allows). Binding
> specific mechanisms to the protocol, as in HTTP/1.1, would be an error IMO.

Binding what exactly? If you look through RFC 2616 there is no mention 
of authentication mechanism limits.

The mechanisms which we are all so familiar with today are defined in 
RFCs outside of the HTTP protocol spec and layered on top of HTTP 
headers. There is none of them which can be pointed at specifically and 
say "that is only possible with HTTP" or "HTTP only permits X, Y, Z 
mechanisms". HTTP simply defines some headers which are reserved for 
sending auth credentials per-hop or end-to-end, limiting to two sets of 
credentials concurrently on any hop. It is the application and 
implementations which determines which one is more appropriate to be 
used on any transaction and/or hop.

*Every single claim* that HTTP-auth is broken and needs re-designing 
seems to me to be based on the flawed assumption that HTTP-auth is not 
extensible and that the common existing schemes are the only ones HTTP 
permits. Or that somehow a user authenticating with N different and 
fragile mechanisms for one transaction is a good thing (I rather 
disagree, the UX on that would be tricky and implementation nightmares).

Amos

Received on Tuesday, 16 July 2013 12:55:06 UTC