Interestingly, there actually isn’t any technical difference between securing a websocket connection and securing a stateless HTTP request either. Authentication on a websocket connection has to happen during the initial handshake, and according to the RFC, the handshake is not required to be performed over HTTP, but since that’s what everything runs, that’s how it’s handled in practice on every server ever. The server can reject the connection before responding with the 101 to switch to the websocket connection, in which case everything stays HTTP.
In practice, handling auth on a websocket connection is a bit different from a regular HTTP request since the browser APIs don’t allow passing arbitrary headers on a websocket handshake (even though the RFC says they are supposed to), but it’s still just a stateless HTTP request until the 101 has been received by the client.
The on_mount/3 callback is a leaky abstraction of the websocket handshake. I actually think that on_mount/3 should be named before_connect/3 and only run once in the disconnected state. handle_params/3 always gets called after the socket is connected anyway, so it makes more sense to load state in that callback and leave on_mount/3 for establishing the connection itself. Worst case scenario, there could be a separate on_connect/3 callback that gets called after the connection is accepted ({:cont, socket} returned from before_connect/3) but before the first call to handle_params/3. I think it probably wouldn’t get used much in practice though since the URL params should hold the state of the page, so “initialization” is just whatever data gets loaded when the params map is empty.
Thinking about this, since we have the connected?/1 helper function, this connection pattern could actually be implemented in LiveView as-is by simply putting an if !connected?(socket) do at the top of the on_mount/3 implementation with no else block. I might try that out. 
