Support GraphQL over WebSocket authentication via "connect_init" message

[fschmuck]

I implemented my spring-graphql application according to the samples in the repository. The client is a apollo-angular application which receives the jwt from a separate keycloak server. When the client establishes the websocket connection, it sends the jwt in the payload of the connect_init message as described in the graphql-ws documentation.

INIT MESSAGE FROM APOLLO CLIENT: `{"type":"connection_init","payload":{"Authorization":"Bearer <VALID_TOKEN>"}}`
ACK MESSAGE: `{"type":"connection_ack","payload":{}}`
SUBSCRIBE: `{"id":"06b0c701-bf03-4630-a32e-6e3b4da513df","type":"subscribe", <GRAPHQL_SUBSCRIPTION>}`
ERROR: `{"type":"error","payload":[{"message":"An Authentication object was not found in the SecurityContext","locations":[],"extensions":{"classification":"DataFetchingException"}}],"id":"<ID>"}`

The subscription method in the controller is annotated with @PreAuthorize("isAuthenticated()").
I use spring-boot-starter-oauth2-resource-server to validate the jwt against the keyset of the keycloak server.

I do not understand how to validate this jwt and populate the SecurityContext with data. Every sample out there seems to use STOMP endpoints.
Could somebody explain to me how to handle this properly?

Thank you

[rstoyanchev]

It should just work, the context from the websocket handshake should propagate to your controller method but we might be missing something. If you have a repro handy, please do provide it, or otherwise we'll put one together. There is an issue to improve the samples.

[fernanfs]

I'm running into the same problem. Although, I'm using the webflux variant.

After digging around in the codebase, there doesn't seem to be any support for authentication based on the payload of the init message. It might work, if the Authorization header was specified in http request that initiated the connection upgrade, but the WebSocket API on the client (ES/JS) doesn't provide any means (by default) to provide the header. Thus, providing the token using the HTTP header is not the best way to achieve that.

The suggested way to authenticate with apollo, for example, is to use the init message and transfer the token as the payload:
https://www.apollographql.com/docs/react/data/subscriptions/#5-authenticate-over-websocket-optional
The appropriate API is documented in the link above.

But there is no counterpart to that on the server side. I've been digging around in the spring-graphql codebase and found, that the implementation of a custom WebSocketGraphQlHandlerInterceptor could solve that issue. Unfortunately, I don't know exactly where to start.

In general, a WebSocketGraphQlHandlerInterceptor implementing the methods as follows:

• handleConnectionInitialization:
  on every new connection, inspect the payload and extract the token. This token should then be converted to a SecurityContext and stored for the lifetime of the websocket connection. (No idea where to start to implement that. AuthenticationWebFilter might be the right place to look at?)
• intercept:
  every incoming call should be wrapped with the appropriate SecurityContext. This might be very similar to ReactorContextWebFilter, but here I'm not sure at all.
• handleConnectionClosed:
  here the stored SecurityContext should be removed

If anyone could tell me, whether or not that would be a feasible approach, I'm more than happy to give the implementation a shot.

In addition, I'm willing to provide a sample repository. Any suggestions on how to mock an openid authentication system which ideally runs embedded in SpringBoot? With such an embedded "small footprint" authentication system, it would be easy to provide a truly self contained example.

[fernanfs]

Well, I tried to implement something as outlined in my previous post. Unfortunately, I failed.
I was able to access and decode the Jwt Token I use in the handleConnectionInitialization. I essentially reused the whole authentication logic, that is used with the oauth resource server integration. Once the Authentication object has been created, I store that object in a map, associated with the websocket session id.

But: in intercept there is now way for me to associate the incoming request with the websocket session. Thus, I can't determine which authentication I should use.

To be honest, this really seems to be a serious flaw in the current implementation and API design. Even with some listeners (or interceptors) in place, with different or extended APIs, you would still need to reimplement the validation logic, that has already been configured through spring security. But that configured logic, can not be reused, as it is tailored for the ServerWebExchange and explicitly bound to that. And there is no ServerWebExchange when the token is sent as a part of the connection init message.

[rstoyanchev]

Thanks @fernanfs for elaborating and apologies for the confusion. I had misread the original report, not realizing it's about authentication through the "connection_init" message payload, which is not something we support at the moment.

As an initial step, I've updated methods on WebSocketGraphQlInterceptor to have a WebSocketSessionInfo argument instead of the WebSocketSession id. Likewise, the intercept method can access the same by downcasting the request to WebSocketGraphQlRequest.

This allows you to correlate the session between the initial handleConnectionInitialization and subsequent intercept methods for each request on the session, and you can also store data via WebSocketSession#getAttributes. This should make it possible to complete the experiment you described above.

I realize we need to support this as a first class option though, by providing a GraphQL over WebSocket interceptor for Spring Security. I'll schedule to explore that possibility for 1.0.

[fernanfs]

That is great news @rstoyanchev, thanks for adding that to the codebase! I'll give that a shot as soon as possible.

Supporting authentication through the connection_init message will indeed be challenging. But not actually on the GraphQL side - rather more on the spring security side.
Spring Security and the appropriate configuration and object instances arising from that configuration, are tightly coupled to the ServerWebExchange. This poses a problem, as there is no ServerWebExchange in case of the WebSocket messages. I had no other chance than to recompose a hierarchy of objects to perform the validation of my JWT token, essentially duplicating what I configured for spring security oauth resource server.

[rstoyanchev]

We'll certainly want to provide built-in support for this but in the mean time, not sure @rwinch or @jzheaux if you have any further advice regarding @fernanfs's last comment.

[rwinch]

@fernanfs You are right that if you want to support authenticating over HTTP and WebSocket you will need to provide configuration for both options. Since there is no support for WebSocket, you will need to manually configure that. The DSL provides wiring for the controllers which are written as WebFilter instances. These are coupled to ServerWebExchange. It also wires up ReactiveJwtDecoder which is not coupled to ServerWebExchange. You can reuse the ReactiveJwtDecoder in the web socket code but you will need to obtain the JWT and pass it into the ReactiveJwtDecoder.

[rstoyanchev]

We've discussed this. While it's too late for 1.0, we can provide samples soon to use as a workaround until fully integrated in an upcoming follow-up release.