Subject: [hybi] Proposal for extensible authentication framework

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 13 Aug 2011 14:06:56 +0200

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
<[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 13 Aug 2011 18:00:20 +0300

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:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi