When your Phoenix socket has no identity at all (and why that was the right call)

Wycliff Ogembo — Wed, 22 Apr 2026 17:38:59 +0000

Most Phoenix Channel tutorials assume the socket carries an authenticated identity — a user token, a session cookie, something that connect/3 validates. That's the path of least resistance and it works for 95% of apps.

I ended up writing one where it was actively wrong.

The setup

I was building a zero-knowledge messaging app — two people share a secret and talk through a web channel, and the entire threat model hinges on the server not knowing who is talking to whom. If the socket had any durable identity, it would become a correlatable identifier. That identifier would exist in logs, in crash dumps, in whatever the BEAM's Process.info returns during a hot debug session.

I needed a socket the server literally could not identify.

The code

It turns out this is shorter than the normal path:

defmodule MyAppWeb.AnonSocket do
  use Phoenix.Socket
  channel "anon_room:*", MyAppWeb.AnonRoomChannel

  @impl true
  def connect(_params, socket, _connect_info), do: {:ok, socket}

  @impl true
  def id(_socket), do: nil
end

That's it. connect/3 accepts everyone. id/1 returns nil, which tells Phoenix.Socket there is no identifier to use for per-user broadcasts. The socket is equally anonymous to Phoenix and to anyone reading the code.

Where auth actually lives

All access control moves into Channel.join/3:

def join("anon_room:" <> room_hash, params, socket) do
  %{"access_hash" => access_hash, "sender_hash" => sender_hash} = params

  with :ok <- validate_hex(room_hash),
       :ok <- validate_hex(access_hash),
       :ok <- validate_hex(sender_hash),
       {:ok, room} <- Rooms.get_active_room(room_hash),
       :ok <- Rooms.verify_access(room_hash, access_hash) do
    {:ok, assign(socket, room: room, sender_hash: sender_hash)}
  else
    _ -> {:error, %{reason: "unauthorized"}}
  end
end

The three hashes are all SHA-256 hex strings computed client-side from a shared secret. The server verifies them against its database but never sees the secret itself.

What you give up

Phoenix's per-user utilities stop working because there is no "user":

Phoenix.PubSub keyed by socket.id — doesn't apply; there's nothing to key on.
Presence tracking by user ID — works only at the topic level (who is in anon_room:<hash>), not across topics for the same user.
Server-side rate limiting by identity — you have to fall back to IP-based rate limiting at the endpoint/plug layer, since the channel has no identity to throttle.

What you keep

The channel itself still works normally — push, broadcast-to-topic, handle_in, all of it.
You can still store assigns per-socket (assign(socket, room: room)). You just can't share identity across sockets for the same user.
A smaller attack surface: a socket that never authenticates cannot leak authentication state.

The useful mental model

Normal Phoenix sockets are like a long-lived session: you log in once, then every channel inherits that identity. The sessionless variant is more like a capability-URL system — each channel join carries its own bearer credentials, and the socket is just a pipe.

For most apps this is unnecessary complication. For apps where the socket mustn't correlate activity across channels, it's the simpler mental model.

If you've got a use case where this pattern fits, I'd love to hear about it — I've only seen it come up a couple of times. (The app that drove this design: sTELgano, AGPL-3.0.)