[keycloak-user] WebSockets

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Tuesday, 11 August, 2015 4:22:18 PM
> Subject: Re: [keycloak-user] WebSockets
> 
> 
> 
> 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.

Yes - it would be handled by the application, but we'd provide some helper classes on both the server-side and the client-side to do it

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