[keycloak-user] WebSockets

[Bob McWhirter]

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 at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-user at 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 <http://bill.burkecentral.com/>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150811/89cf3208/attachment.html