Re: Authentication over HTTP

Amos Jeffries <> Wed, 17 July 2013 06:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B74121F9C82 for <>; Tue, 16 Jul 2013 23:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.273
X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ud-teIIKPYcS for <>; Tue, 16 Jul 2013 23:51:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0D14721F8438 for <>; Tue, 16 Jul 2013 23:51:41 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UzLZh-0003nD-D4 for; Wed, 17 Jul 2013 06:50:57 +0000
Resent-Date: Wed, 17 Jul 2013 06:50:57 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UzLZX-0003ls-H8 for; Wed, 17 Jul 2013 06:50:47 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1UzLZW-00039C-Fd for; Wed, 17 Jul 2013 06:50:47 +0000
Received: from [] ( []) by (Postfix) with ESMTP id 24AA4E6F66 for <>; Wed, 17 Jul 2013 18:50:23 +1200 (NZST)
Message-ID: <>
Date: Wed, 17 Jul 2013 18:50:18 +1200
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=-3.104, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UzLZW-00039C-Fd 5c17a6adb8c21f0b07f32c12efe60857
Subject: Re: Authentication over HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/18818
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.