Websocket servlet filter to fake JWT token in auth header

[cen1]

Since whatwg refuses to add custom authorization header support to the browser WebSocket API spec I am forced to pass my JWT token as a query string when connecting to WS server.

I still wanted to retain a shred of decency and use @Authenticated and the Keycloak adapter as it is out of the box without implementing custom authorization code or protocol in WS messages.

So I wanted to be clever and write a Servlet Filter which would transform incoming query param into Authorization: Bearer header with highest priority (before security kicks in).
Unfortunately I can't do that with quarkus-reactive as it does not provide the servlet spec (does it?) and I am not switching to undertow just to fix this issue.

Any idea or hack workaround how to achieve this? I want manual JWT auth check only as last resort.

The saddest thing is that using non-browser WS implementation (e.g node) that support adding custom headers to WS handshake, everything just works beautifully out of the box.

[quarkus-bot[bot]]

/cc @sberyozkin

[sberyozkin]

@cen1 Can you look please at #20157 and see if it helps ?

[cen1]

As I mentioned at the end of my question, security context does indeed work fine for websockets when connecting with a WS client that support setting custom headers. If that patch series is about proper security context working for websockets that does indeed work fine.

The issue is when using JavaScript Browser API which does not allow you to set a custom Authorization: Bearer header in the protocol upgrade. This forces you to either use a query parameter or abuse the subprotocol field to pass the token.

I am looking for a way to keep using @Authenticated/@RolesAllowed which already work fine by transforming an incoming query parameter into an Authorization header before the security chain.

[sberyozkin]

@cen1 So in your original description you said you were looking for Any idea or hack workaround how to achieve this... So wouldn't using a subprotocol field to pass the token qualify as a hack ? Other than that I can only think about the custom WS bindings which could be use to keep the token around but I'm not sure how it can be implemented at the Quarkus level, perhaps we need an enhancement PR

[cen1]

Yes, sorry for not making myself clear. When I was asking for a hack/workaround I specifically meant for a way to transform incoming request param into a header for the websocket http upgrade request (the TODO part in the code sample below).

This works but it's ugly and I want to avoid it:

public void onOpen(Session session) {
  String token = session.getRequestParameterMap().get("token").get(0);
  JsonWebToken jwt = parser.parse(token);
}

What I would like to achieve is this:

JS

let token = keycloak.token;
let ws = new WebSocket(`ws://localhost:8080/sessions?token=${token}`)

Quarkus

@ServerEndpoint("/sessions")
@ApplicationScoped
@Authenticated
public class SessionResource {
  
    // TODO: register some kind of middleware (interceptor, filter) that transforms ?token= into Authorization: Bearer <token>
    // this way @RolesAllowed works without modifications and we don't need to perform manual JWT validation

    @OnOpen
    @RolesAllowed("player")
    public void onOpen(Session session) {...}
}

[sberyozkin]

@cen1 Sure, that would be ideal, makes sense. I'd like to propose for you to open an enhancement request and consider supporting it with a PR, I think there should be a way for Quarkus WS code to recognize such a query parameter similarly to the way it was done in the PR I linked to (for example, may be recognize custom WsFilter implementation etc)...

[stdcout42]

Did anything ever come of this?

[cen1]

I did not find the time to work on this personally yet.