[keycloak-user] WebSockets

[Bill Burke]

On 8/11/2015 1:23 AM, Stian Thorgersen 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.
>

I just don't see how this is feasible beyond providing a simple 
servlet-aware helper class on the server side that would be used only on 
connection setup.  But you still have the problem of when the access 
token expires.  That would have to be handled by the application because 
the protocol would be app specific.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com