For at least opening the web socket, assuming the user has the cookie or bearer token already, it can go with the initial HTTP upgrade request.  Browsers send cookies on the WebSocket connect, and I think you can add the bearer token if that’s how you’re flying.

Subsequent re-auth, as Bill said, should be up to the user and how he’s using the socket.

-Bob


On Aug 11, 2015, at 1:23 AM, Stian Thorgersen <stian@redhat.com> wrote:



----- Original Message -----
From: "Bill Burke" <bburke@redhat.com>
To: keycloak-user@lists.jboss.org
Sent: Monday, 10 August, 2015 4:10:36 PM
Subject: Re: [keycloak-user] WebSockets



On 8/10/2015 9:48 AM, Juraci Paixão Kröhling wrote:
On 08/10/2015 03:26 PM, Bill Burke wrote:
Once the WeBSocket is established there is
actually no reason to resend the token as the connection/socket remains
open.  HTTP requests are different.  They need to retransmit the token
because HTTP is connectionless and assumes every request is a different
connection. For browser apps, logout can be handled in the regular way
with keycloak.js.  Non-browser apps can just rely on non-browser means.

All the server needs is a way to validate and unpack the token.  Refresh
should be handled at the client side through keycloak.js or some other
oauth library.  For bearer token auth, it is  not the responsibility of
the server to manage the token.

Not sure I get it. Are you saying that my server endpoint should trust
that the client will close the connection once the token expires/is
invalidated?


I didn't say that.  You just don't have to retransmit the token every
request because in WebSockets the connection is already established.

You are going to have to rely on the client to get a new token and
reconnect.  Keycloak can't support every single pet protocol implemented
on top of WebSockets.  We can only offer token validation on HTTP
Upgrade out-of-the-box plus an API to unpack and validate a token.
Anything more and you'll have to implement it yourself.

IMO, abort with an error code, the client destroys the WebSocket,
refreshes the token via OAuth,  and reestablishes the WebSocket.  Its
the simplest way and we can provide support for it OOTB with Keycloak's
adapter lib.  Otherwise you'll have to implement anything more complex
yourself.

I know there's no standard protocol, but I still think the token should be sent through the socket itself not as part of the url. I don't like sending it as the url for one, secondly having to drop and re-create the socket every time the token expires negates the purpose of web sockets somewhat.



--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user


_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user