How to provide the token over WebSocket?

[phryneas]

When making a HTTP connection, according to the documentation, I can send the token in a header like X-Tunnel-Authorization: tunnel <TOKEN>.

Now, the normal WebSocket class has no way of sending any headers.

So, how can I provide this token on a WebSocket connection?

If this is not possible yet, may I request this as a feature?

Maybe something like wss://my-id-7095.euw.devtunnels.ms/?tunnel-token=token?

[phryneas]

Strike this comment - it does work with the ws package as client, which is a start.

[phryneas]

After going through the very painful discussion in whatwg/websockets#16, I realize that's not a viable option in all environments though 😢
Please add some alternative means of adding a token - this is nonstandard, and while some engines ship it, it's questionable if any browsers will support it within the next few years.

[jasongin]

One alternative that might work, depending on your scenario, is to let the websocket connection rely on cookie authentication. If you first go through a browser sign-in for the same tunnel, then after that the websocket requests to the same tunnel domain will include the cookie for authentication.

1. Create a tunnel, and open the tunnel URL in a normal browser window.
2. You'll be prompted to sign in to access the tunnel (assuming the tunnel does not allow anonymous access). This sets a cookie so that you don't need to sign in again for access to the same tunnel.
3. After that, a browser websocket connection should also be authenticated automatically using the same cookie.

Passing the token via a query parameter is generally not a good approach because URLs including query parameters are likely to be logged (by proxy servers as well as the host server).

We have considered adding a capability to pass an authentication token via the websocket subprotocol, which is a common workaround mentioned in the issue you linked. The tunnel service supports that today for client connections using the tunnel SDK, but not for regular websocket client connections to forwarded ports; that would be a minor feature request.

[phryneas]

One alternative that might work, depending on your scenario, is to let the websocket connection rely on cookie authentication. If you first go through a browser sign-in for the same tunnel, then after that the websocket requests to the same tunnel domain will include the cookie for authentication.

Unfortunately, that's not an option.

I'm building a VSCode extension that acts as a DevTools host so that other programs can connect to - so you'd have for example a node process or a React Native appplication trying to use that tunnel - no browser there. (Other users might, of course, use a browser, so we cannot tell everyone to use the ws package).

We have considered adding a capability to pass an authentication token via the websocket subprotocol, which is a common workaround mentioned in the issue you linked. The tunnel service supports that today for client connections using the tunnel SDK, but not for regular websocket client connections to forwarded ports; that would be a minor feature request.

So, essentially the first message would have to be some kind of { type: "authentication", token: "..." } message?

That would work! I would be incredibly grateful if you could get that in!