Re: [hybi] About authentication mechanism

[Greg Wilkins <[e-mail]>]

Sorry if this is a duplicate - there was an error in sending and I
also notice I left out a .net from my example:


I do not think that this WG should be in the business of mandating
Authentication mechanisms. There is no one-size-fits all
authentication mechanism and best practises change. I believe that we
need WS to support a variety of authentication mechanisms and thus
avoid the "you don't want to use that mechanism" debate.

For cookie based authentication mechanisms, the protocol already
supports sending and setting cookies in handshakes and handshake
responses.  However I cannot see any requirements on the browsers to
actually send any cookies - so perhaps we need to strengthen the spec
here with some recommendations (ie SHOULD send appropriate cookies
rather than MAY send).

For the HTTP authentication mechanisms of BASIC and DIGEST, the spec
does allow a 401 challenge to be sent, however I do not think that we
currently don't explicitly allow the WWW-Authenticate or Authorisation
headers in the handshake.   So I think we should add a point in 5.1
saying that a handshake request MAY include other HTTP headers such as
Authorisation.  Currently we only say MAY include
Sec-WebSocket-Protocol, Sec-WebSocket-Extensions and cookie headers -
which by omission implies we can't have arbitrary headers (which I do
not think was the intent).       Note I do recognise that there are
issues with collecting credentials for these mechanisms and thus I
think we should defer to the browsers if and how they will be
supported, but we should definitely allow them in the protocol.

For token passing authentication mechanisms, there is currently no way
for users to set HTTP headers in the handshake.  This is probably a
good thing!    The only user settable field in the handshake is the
subprotocol fields, and as I have said before, I would not be
surprised if this was used (or abused?) to send OAUTH tokens. Perhaps
usage of OAUTH is a subprotocol and we should allow multiple
subprotocols and  parameters to subprotocols for passing data, eg.


       GET /chat HTTP/1.1
       Host: server.example.com
       Upgrade: websocket
       Connection: Upgrade
       Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
       Sec-WebSocket-Origin: http://example.com
       Sec-WebSocket-Protocol:oauth.net;token=9AF4023B3CDFAA021C3456BFAA,chat,superchat
       Sec-WebSocket-Version: 8

       HTTP/1.1 101 Switching Protocols
       Upgrade: websocket
       Connection: Upgrade
       Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
       Sec-WebSocket-Protocol: oauth.net,chat



So in summary, I think to better support flexible authentication we should
1. say that clients SHOULD send appropriate cookies (rather than MAY)
2. expand 5.1 to so that clients MAY send arbitrary HTTP headers,
including Authorisation (which can be listed as an example).
3. Allow multiple parameterised subprotocols, so that they may be used
for token based authentication.


cheers