Re: [hybi] Supporting OAUTH-like authentication?

[Iñaki Baz Castillo <[e-mail]>]

2011/7/29 Philipp Serafin <[e-mail]>:
> 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)

I don't like point 1 (due to same reason given by Greg in next mail).


> 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".


Let me propose another approach:


1.: Client connects to server using subprotocol "foo". Client does NOT
know which authentication the server requires (neither if the server
does require authentication or not). Please don't assume that a
specific WS subprotocol always requires the same authentication
mechanism. It's the server who must decide it at any time.

2.: Client and server perform successful WS handshake. The server
requires (in this case) Digest authentication so the 101 response
contains a *standard* header defined in WS core draft:

  Sec-WebSocket-Authenticate: Digest realm="domain.org",
     nonce="4e45a9e60000856cac2a6dd2e4edeba1a83e2ceb7137c3d0",
     qop="auth"

3.: Client supports Digest authentication so it taken the
username/passwd from somewhere (WS-API) and starts speaking
"auth+digest" WS subprotocol (which should be defined in some RFC).

4.: So client sends a WS message containing the computed Digest credentials.

5.: Server confirms that authorisation was successful in a WS reply.

6.: Client and server exchange messages as specified by subprotocol "foo".



Now replace Digest with OAUTH or whatever. Of course, all those
authentication mechanism should be standarized by different RFC's to
be used in WS. Each one would involve a defined WS subprotocol
("auth+digest", "auth+oauth").

A WS server could reply more than one Sec-WebSocket-Authenticate
header (one with "Digest" and another one with "OAUTH") in case it
supports both, so the client could choose which one to use.



-- 
Iñaki Baz Castillo
<[e-mail]>