Description

There are two cases that would be good to support:

1. SPA authenticates users with an OpenId Connect provider (independently of Quarkus) and sends bearer access token with a Web Socket upgrade request

2. Quarkus OIDC authenticates users and the authenticated users do a web socket upgrade request, with Quarkus WS Next HTTP Upgrade handler picking up an OIDC session cookie - this option must fail if no CORS or CSRF protection is activated

Quarkus users have been asking how to handle these cases for years, it is really the high time, with WS Next helping users so much to do WS, offer a decent security support for native Java Script WS API calls.

Implementation ideas

For the SPA sending a bearer token, using Secure-WebSocket-Protocol is a defacto work-around, we should offer a support for this option, I've found https://ably.com/blog/websocket-authentication informative, and this Kubernetes PR specifically.

For the user with the OIDC session cookie, we have to enforce CORS. I'd like to demo this case with the Quarkus LangChain4j secure chat bot demo.

I suppose in both cases we should have a custom WS HTTP Upgrade handler which will use OIDC TenantIdentityProvider to verify the identity...

I'm not sure how to structure it correctly, I can think of 2 options:

1. WS-Next introduces an SPI which quarkus-oidc will depend upon and will implement a custom HTTP Upgrade handler.
2. We have a very light quarkus-oidc-websockets-next extension which only ships a custom HTTP Upgrade handler

CC to the WS experts: @mkouba @michalvavrik