Subject: [hybi] Supporting OAUTH-like authentication?

From: Greg Wilkins <[email-masked]>
Date: Fri, 29 Jul 2011 10:44:45 +1000

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

---

From: Philipp Serafin <[email-masked]>
Date: Fri, 29 Jul 2011 03:00:48 +0200

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:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 29 Jul 2011 11:34:11 +1000

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