Re: [hybi] Proposal for extensible authentication framework

[Hannes Tschofenig <[e-mail]>]

Take a look at 
http://tools.ietf.org/html/draft-williams-rest-gss-00
and see whether this fits your needs of an extensible authentication framework.

Ciao
Hannes

PS: OAuth is btw not protocol that authenticates the end user. Instead the handshake allows the end user to authorize the subsequent exchange of data. 

On Aug 13, 2011, at 3:06 PM, Iñaki Baz Castillo wrote:

> Hi, I copy&paste this text I've replied in other thread as it could
> become a different concept (it not just about OAUTH authentication,
> but about anyone).
> 
> It is a proposal (for sure it must be improved/corrected) for
> including a *standard* extensible authentication mechanism in
> WebSocket protocol. I explain it with an example:
> 
> 
> 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 (or in other
> separate draft):
> 
>  Sec-WebSocket-Authenticate: Digest realm="domain.org",
>    nonce="4e45a9e60000856cac2a6dd2e4edeba1a83e2ceb7137c3d0",
>    qop="auth"
> 
> 3.: Client supports Digest authentication so it takes the
> username/passwd from somewhere (WS-API stuff), computes the Digest
> response 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 authorization 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 (i.e: one with "Digest" and another one with "OAUTH") in case it
> supports both, so the client could choose which one to use.
> 
> The point here is that, even if during the WebSocket handshake the WS
> subprotocol "foo" is negotiated, the presence of a
> Sec-WebSocket-Authenticate header in the 101 response
> implies that before speaking "foo", the client must authenticate using
> the mechanism in such received header (or one of them if there are N
> headers). This is, before speaking "foo" subprotocol, the client MUST
> speak "auth+digest" or "auth+oauth" or whatever.
> 
> A doubt coming to my mind is: if there are two
> Sec-WebSocket-Authenticate headers (offering Digest and OAUTH) and the
> client chooses OAUTH (so starts speaking "auth+oauth"), how would the
> server realize that the first WS message is "auth+digest" or
> "auth+oauth"? AFAIK such information is not carried within WS messages
> (but just during handshake).
> 
> A proposal for this last subject: the "auth" protocol could be
> standard, and the chosen mechanism would be indicated in a WS message
> within "auth" protocol (along with the rest of fields required for
> each authentication mechanism). "auth" WS messages could be, for
> example, a JSON object like:
> 
>  "auth": {
>    "mechanism":  "Digest",
>    "data": {
>       "username": "alice",
>       "nonce": "aksdhakjdshakjs";
>       "response":  "aksdh89akjhsdke",
>       "qop": 1
>    }
>  }
> 
> This is, "data" object structure would depend on the chosen "mechanism".
> 
> Opinions?
> 
> 
> -- 
> Iñaki Baz Castillo
> <[e-mail]>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi