Re: Authentication over HTTP

On 17/07/2013 6:33 p.m., David Morris wrote:
>
> On Wed, 17 Jul 2013, Amos Jeffries wrote:
>
>> On 17/07/2013 5:34 a.m., Nico Williams wrote:
>>> On Tue, Jul 16, 2013 at 7:54 AM, Amos Jeffries wrote:
>>>> *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).
>>> That's either a strawman or you misunderstood the arguments against
>>> doing authentication in HTTP.  It's not that "HTTP auth is broken",
>>> but that HTTP is the *wrong layer* -- that's not because HTTP or HTTP
>>> auth is broken, but because properties of the stack of protocols
>>> spoken make HTTP auth a problematic proposition.
>>>
>>> BTW, I've not see any arguments about N different mechanisms (fragile
>>> or not) being a problem.
>> Maybe I have been misunderstanding some of them. But the auth proposals I've
>> seen in the last few years all seem to fall into three brackets with regards
>> to their claims about HTTP:
>>
>> 1) "HTTP auth is broken". Aka "do it all in payload entities and have HTTP
>> endpoints interpret those" ... well so what? payload format is not HTTP. Good
>> luck but go away and do it at a different layer.
>>
>> 2) "HTTP auth is broken". Aka the headers dont let me login user X to proxy A
>> and proxy B at the same time, in the same chain, with different credentials
>> all controlled by user X ... seem to be making a few wrong assumptions about
>> how HTTP works there. Go away and do (1) instead the user-application ha sa
>> lot more control over end-to-end pathways in application layer.
>>
>> 3) "HTTP auth is broken". Aka its missing a scheme to do mechanism Z ... and
>> we do see these followed by specs to do Z in HTTP. But none of them are
>> exactly replacing the existing HTTP mechanism design, just extending it as it
>> was intended to be extended.
>>
>> What am I missing?
> How about the user experience sucks because the authentication doesn't fit
> into the style/face of the application and doesn't provide sufficient user
> context for the prompts generated by the auth mechanicanism so the
> application owners design and implement their own approach?

  HTTP provides key=value parameters on the mechanism headers for that 
kind of thing. What can't be expresed as such comes under #1, 
application layer problem. For example, how in heck is HTTP or any 
protocol going to enforce "thou shalt have no password longer than S 
characters long" when the protocol never sees the password at all? or 
similar *GUI* restrictions.

>   Oh, and no
> logout mechanism to cancel browser caching of credentials?

In the stateless HTTP "login" is done by delivering credentials or 
requesting them. But how *do* you "logout" in a stateless protocol? 
Nobody (self included) has produced anything like a good proposal spec 
for resolving that problem AFAIS.

Amos

Received on Wednesday, 17 July 2013 06:50:47 UTC