Re: Authentication over HTTP

[David Morris <[e-mail]>]

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 <[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:
> 
> 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? Oh, and no
logout mechanism to cancel browser caching of credentials?