Re: [hybi] Supporting OAUTH-like authentication?

Greg Wilkins <gregw@intalio.com> Fri, 29 July 2011 01:34 UTC

Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB64921F8BB3 for <hybi@ietfa.amsl.com>; Thu, 28 Jul 2011 18:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.89
X-Spam-Level:
X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZfTZbCPf2wE for <hybi@ietfa.amsl.com>; Thu, 28 Jul 2011 18:34:12 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28E1021F8BB1 for <hybi@ietf.org>; Thu, 28 Jul 2011 18:34:12 -0700 (PDT)
Received: by vws12 with SMTP id 12so2933311vws.31 for <hybi@ietf.org>; Thu, 28 Jul 2011 18:34:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.236 with SMTP id o12mr688641vdg.497.1311903251500; Thu, 28 Jul 2011 18:34:11 -0700 (PDT)
Received: by 10.52.114.228 with HTTP; Thu, 28 Jul 2011 18:34:11 -0700 (PDT)
In-Reply-To: <4E320640.2080408@gmail.com>
References: <CAH_y2NHZuYTbpMnrHU65JtZzRE-pbiXnRRh=rOTknTbc_+8gow@mail.gmail.com> <4E320640.2080408@gmail.com>
Date: Fri, 29 Jul 2011 11:34:11 +1000
Message-ID: <CAH_y2NGf44v770VX8+bsFppokJb0_jtTvAA0zrM89uoJ1v6UJQ@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Philipp Serafin <phil127@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Supporting OAUTH-like authentication?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 01:34:13 -0000

Philipp,

Doing the auth within the connection is certainly possible, maybe even
desirable.  However, I think that there could be a concern about not
wanting to accept connections from non-authenticated sources, as to do
so already represents an allocation of resources.    There are also
extra RTT's involved in token exchange after the handshake.

So failing giving access to HTTP headers, doing oauth the "normal" way
in headers in the handshake will not be possible.    Those wanting
authentication in the handshake can probably kludge it now using the
protocol string.      So do we want to better facilitate auth in the
handshake.

Note also, that with your counter example, there are probably things
we could do to make it more elegant.  For instance, perhaps we want to
allow multiple sub-protocols so we don't have to come up with
"foo+oauth", "bar+oauth" etc and instead just negotiate "oauth,foo"

Eitherway, I think we need to step through (probably implement), some
common authentication mechanisms to see how they work with the current
protocol and to see how we can improve support for them.

cheers




On 29 July 2011 11:00, Philipp Serafin <phil127@gmail.com> wrote:
> Wouldn't it be better to move the token exchange into the actual WS
> connection where we have efficient two-way communication available?
>
> 1.: Client connects to server using subprotocol "foo", which is known to
> use OAuth as authentication (or e.g. "foo+oauth", if this should be
> decided on per-connection basis)
> 2.: Client and server perform successful WS handshake
> 3.: Server sends token and authority URL in a WS message.
> 4.: Client gets token authorized
> 5.: Client sends authorized token back in a WS message.
> 6.: Server confirms that authorisation was successful.
> 7.: Client and server exchange messages as specified by "foo".
>
> Am 29.07.2011 02:44, schrieb Greg Wilkins:
>> All,
>>
>> Currently the protocol allows arbitrary headers, so in theory an
>> authentication mechanism like OAUTH could be implemented by exchanging
>> tokens in the headers of the handshake.    But the js API does not
>> allow an application to set or see HTTP header from the handshake (nor
>> should it), so that is not available as a general mechanism for token
>> passing auth like OAUTH.
>>
>> So what other options do we have to pass tokens in the handshake?
>>
>> Cookies - this is possible, but kind of defeats the purpose of  token
>> passing auth if tokens are to be sent/set in a way that facilitates
>> wider access to them.
>>
>> Extensions - we could say that an OAUTH extensions is required to
>> manipulate the headers of the handshake with OAUTH tokens, but I
>> expect that there will be a very high barrier for an extension to be
>> included in browsers, so I think that is probably a non starter (at
>> least until a defacto-standard auth mechanism emerges).
>>
>> Subprotocol/CloseEvents - Subprotocol is a user controlled field sent
>> by the handshake and closeEvents contain a reason string that could
>> originate from the server application/framework.     Thus I would not
>> be surprised to see these fields used (misused?) to send challenges
>> and pass tokens eg.
>>
>>  1. Client connects to server with oauth subprotocol.
>>  2. Server accepts connection but immediately closes with a reason
>> string containing a token and/or authority URL. ( might be able to be
>> done with a 403 HTTP response if the HTTP reason string is passed to
>> the onerror call back ?? ]
>>  3. Client gets the token signed by an/the authority
>>  4. Client connections to server with oauth;token=value subprotocol
>>  5. Server validates authorisation of token and accepts connection.
>>
>> [ forgive me if that is not exactly how oauth works or correct
>> terminology ... but it is something like that ]
>>
>> Is this a good usage of the subprotocol field/reason fields?
>>
>> Is there a better way to integrate such authentication into the handshake?
>>
>>
>> cheers
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>
>