In theory yes, but (there are always buts):

• Long tokens will cause longer message to be sent to the server - you leak information which connections are authenticated
• When you send token via JS you need to store that token in some place that is accessible for JS (for example Local Storage), which makes you susceptible to XSS side-channel attacks

So in general I would generate short-lived token (like 1m) that is fetched just before connecting and then it is sent to the browser as an authentication and isn’t stored anywhere. The token fetching happens over regular HTTP session with http-only cookie.

If you mean the params passed to the Socket object

// on the client                             |--goes to the backend--|
let socket  = new Socket("/socket", {params: {token: window.userToken}})
socket.connect()

then yes, they go straight to the connect/3 callback:

# on the backend
#           |-from the client-|
def connect(%{"token" => token}, socket, _connect_info) do
  # token here is passed from the client
end

Channels — Phoenix v1.8.8 might be helpful.

Off-topic:

AFAIK, the params are encoded into the query string, so they can’t be too large, since the URL length is sometimes suggested to be under 2048 characters (there might be limits by the browser? by the web server? both? not sure).

So the client connects to a URL like ws://example.com/socket/websocket?vsn=2.0&token=some_token_sent_from_client and the backend just decodes the query string and passes it into connect/3.

I agree here, although I have a word of caution about fetching before connecting. If all clients reconnect at once (or in a few seconds window), then you can end up sending a ton of requests to whatever provides your authentication service. For example, the equivalent of 1.2m rpm was being sent to our server when we did this, and it wasn’t specced for that.

One technique to avoid this is to always have a short lived token available. I use a 10 minute token that is fetched every 5-9 minutes to avoid thundering herd effect.