8:26 a.m.
On 8/10/2015 3:30 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de>
> To: "Marek Posolda" <mposolda(a)redhat.com>, "pslegr"
<pslegr(a)redhat.com>, keycloak-user(a)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