Re: [hybi] Supporting OAUTH-like authentication?

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