Re: Authentication over HTTP

[Nico Williams <[e-mail]>]

On Wed, Jul 17, 2013 at 12:59 AM, Amos Jeffries <[e-mail]> wrote:
> On 17/07/2013 5:34 a.m., Nico Williams wrote:
>> On Tue, Jul 16, 2013 at 7:54 AM, Amos Jeffries <[e-mail]>
>> 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:

But you don't even list here the argument you listed above, nor give
examples.  Why argue about this anyways?  You and I seem to agree:

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

Yes, do it at a different layer: that's my answer.

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

Oh, I'd never seen this argument.  This is an interesting one because
authentication to proxies is very interesting.  So this one is
definitely a legitimate argument, and one I would make.  Also, this
means I have to think about proxy auth for RESTauth (well, it's
straightforward, but I have to add it).  This is very helpful, thanks!

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

At least the argument you'd made above:

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

I've never seen that argument.