Support websockets in proxies

[mike-marcacci]

So far we've been able to put off dealing with websockets in the proxies. We've avoided this feature largely because we are are unaware of any published standards for using expiring credentials with long-lived sockets. Additionally, following prior art (such as Heroku's model) requires shared state across instances, which is a total no-go for a tool designed as a lightweight developer convenience.

There are two obvious directions this could take:

Only send credentials when upgrading the connection

This is obviously not a great solution when using JWTs (self-contained access tokens), since it would either have to ignore the expiration timestamp, or terminate the connection on token expiration.

For revocable tokens, however, this could work quite well, since the proxy could poll AuthX periodically to verify continued validity of the credentials.

One other ding to this approach is that while this appears easy to implement over an upgrade HTTP request, the API exposed to browsers for initiating such a request provides no mechanism for specifying headers like Authorization, which means we'd still have to use some non-standard mechanism for passing credentials when the client is a browser.

Require explicit authorization messages

A more robust strategy would require the client to send periodic "authorize" messages containing a new token, in advance of the previous token's expiration. This is certainly more opinionated, but could be accomplished. A message like this could be used:

authx://authorize:(token)

Unlike HTTP, websockets don't provide us a standard mechanism for attaching metadata to messages. The HTTP resource proxy uses headers to pass decoded and verified/fetched scope information along. We could provide an option to pass this same info along in a custom message, but at that would require sufficient customization of the app that the utility provided by the proxy might as well just be written into the app itself.

However, standardizing on this or some other (perhaps similar) pattern could at least lead to basic support in the resource proxy, and provide a mechanism for websockets that could be automatically supported by the web proxy.

---

@krisbarrett recently implemented AuthX websocket support in an internal golang app; this will provide a lot of real-world learnings before adding inevitably prescriptive support to the proxies.