Identity & auth

DioscHub does not authenticate users. Your app already does that. What DioscHub needs is to be told who the signed-in user is, and to be handed the auth artifacts it should forward to your MCP servers on that user’s behalf. That handoff is auth binding, and it is BYOA: you bring your own auth, DioscHub carries it through.

The auth-binding model

The chat widget never handles credentials. Instead, your backend tells DioscHub who the user is, server-to-server, and ties that identity to the widget’s live connection:

1. The widget opens its connection to DioscHub and receives a connection id (wsId). Until it is bound, the widget knows it has no identity yet.
2. The widget posts that wsId to a bind endpoint on your backend (an endpoint you write), carrying your app’s own session cookie so your backend knows who the user is.
3. Your backend calls DioscHub’s POST /auth/bind — server-to-server, authenticated with a secret admin API key — passing the wsId, the user’s identity, and the auth artifacts to forward.
4. DioscHub ties that identity and those artifacts to the connection, and tells the widget it is ready.

From then on, every tool call on that connection runs as the bound user, with the artifacts forwarded as described in Forward the user’s auth.

Note

Identity flows only through this server-to-server bind. Your backend is the one place that asserts who the user is, using your existing session — DioscHub never calls back into your app to look up a user, and the widget never carries a credential.

The auth artifacts

What you hand DioscHub to forward is an opaque map of headers and optional cookies:

{
  "headers": { "Authorization": "Bearer <the user's token>" },
  "cookies": { "session": "<the user's session cookie>" }
}

DioscHub stores these against the connection and forwards them verbatim to your MCP servers on each call. It does not parse or interpret them — their meaning is entirely between your backend and your MCP servers. And because they are forwarded on the transport, never placed in the model’s context, the Assistant stays Credential Blind.

In this section

Implement the bind endpoint The exact POST /auth/bind contract your backend calls: request shape, what identifies the user, and the ownership checks that protect a connection.

Anonymous sessions & sign-in promotion Let a visitor chat before signing in, then promote the same session in place the moment they authenticate — no lost conversation.

---

Next: Implement the bind endpoint.