[keycloak-user] WebSockets

[Bill Burke]

On 8/10/2015 3:30 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Juraci Paixão Kröhling" <juraci at kroehling.de>
>> To: "Marek Posolda" <mposolda at redhat.com>, "pslegr" <pslegr at redhat.com>, keycloak-user at lists.jboss.org
>> Sent: Wednesday, 5 August, 2015 4:20:32 PM
>> Subject: Re: [keycloak-user] WebSockets
>>
>> On 08/05/2015 03:39 PM, Marek Posolda wrote:
>>> Maybe it's
>>> possible the server will poll the client socket and ask for updated
>>> token from the client periodically. I am not sure about the possible and
>>> best option TBH (not have deep websocket knowledge)
>>
>> It is possible, but that goes into the "invasive" approach, as it can be
>> done only with a message going from the server to the client. Doing this
>> at the Keycloak level means that the application has to know how to
>> handle (or discard) Keycloak-specific messages.
>>
>> Honestly, the more I think about it, the more I realize that the best
>> solution would be to get an API from Keycloak that would allow me to
>> validate tokens and extract a principal from it, like what the Request
>> Authenticators do. Even better if this API could call me back from time
>> to time, so that my server part could ask the client part for a renewed
>> token. My client could then send this token in the next payload (not
>> necessarily a payload *only* with the token).
>
> +1
>
> I'm less convinced about including token in URI due to security issues + access tokens are short lived. The better option is to send the access token as a message after the socket is open. If the token is expired the server should return with an appropriate error message so the client knows it needs to refresh the access token and resend to the server. We'd need to support this for multiple languages though :/
>

WebSockets is not a protocol.  It is just a means to send packets of 
data and is not any more sophisticated than that.  Applications 
implement their own protocol on top of it.  So the only way to provide 
something OOTB for WebSockets is to embed the token in a query param on 
HTTP Upgrade requests.  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.



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