Support for websockets with auth-command

[michielbdejong]

In order to support https://github.com/solid/specification/issues/52#issuecomment-682491952, which will become mandatory in NSS version 6.0, we need to be able to send the tokens from the auth headers to the WebSocket server.

The solid-crud-tests are already doing this whenever they open a connection to a WebSocket-pubsub server.

It is my understanding that the current version of ISCAJ stores these tokens inside a closure, and so it would be impossible to send them (unless you add a simple WebSockets-pubsub client inside that closure).

[michielbdejong]

Another option would be you implement a getAuthHeaders function in your API, and that way code that has access to the authenticated ISCAJ instance can call that function to get the tokens out (but add a warning that developers should use this function with care and not store the tokens in an unsafe place)

[NSeydoux]

I'm not very confident on the WebSocket protocol, so what I say may not be accurate, but considering our current architecture, instanciating a WebSocket client the same way we instantiate a fetch function seems like it would fit our current security model better: the WebSocket client can hold the tokens in its closure the same way the fetch does (see https://github.com/inrupt/solid-client-authn-js/blob/master/packages/browser/src/login/oidc/redirectHandler/AuthCodeRedirectHandler.ts), which prevents the token being potentially exfiltrated by a malicious script.

[michielbdejong]

Great, yes please!

[pmcb55]

Just my 2c, but I really like the direction of Streaming requests with Fetch, as pointed out a couple of months ago. I know of course that that approach is very early days, but if/once it becomes widely available that might be a great alternative to WebSockets, with all it's attendant issues.
So I'm just saying I wouldn't necessarily be holding my breath waiting for anyone else to address the current known issues with auth and Web Sockets.

[michielbdejong]

Thanks for managing expectations! :)
Appreciate the transparency.

[acoburn]

I very much agree with @pmcb55's comment. Putting auth commands into the WebSocket protocol as described in https://github.com/solid/specification/issues/52#issuecomment-682491952 is arguably better than having no auth at all, but it's also not an ideal fit. First of all, DPoP doesn't make sense in the context of WebSockets (what htm/HTTP method claim applies here?), and it adds complexity in ways that could be avoided by using a different mechanism.

Streaming fetch is one such option -- it would leverage the existing auth mechanism for ordinary HTTP requests, which is very appealing
Another option is to define a mechanism by which a client can request a session cookie with a particular RS that could be used as a basis for auth. This mechanism could be useful in other contexts, too.

There may be other options, too. But the main point is I am not convinced that the proposed approach to add an auth command to the WebSocket protocol is ultimately going to fly.

[michielbdejong]

Thanks for providing context, Aaron. Sure, I'm aware of all these spec discussions, and I understand if you don't want to spend time building it.

This was just a feature request and it's OK if you don't want to support this in your product!

We have it working in solid-auth-fetcher, so that's what we'll keep using in the Solid OS stack and in the Solid test suite, then.

[michielbdejong]

cc @nicolasmondada let's discuss this situation in our meeting today!

[michielbdejong]

See also https://gitter.im/solid/test-suite?at=5ff45862ac9d8e7463f031fa

[nicolasmondada]

Support for authenticated websockets is now available in PodSpaces as part of Inrupt's 1.1 release. Here's the docs page to learn more about how to use them in your web app.