SurrealDB HTTP JWT session scope to WebSocket live-query subscription interoperability

Direct answer

No. Authenticating an HTTP request with a JWT does not implicitly establish namespace and database scope on a subsequently opened WebSocket connection. The JWT is a portable credential; scope selection belongs to the individual transport session. Authenticate the WebSocket with the same JWT, explicitly select the intended namespace and database on that socket, and only then issue the live query. There is no transport-agnostic SurrealDB session mechanism that copies HTTP scope into a WebSocket subscription.

Established behavior

• HTTP requests are independent. Scope used by one request does not become the default for later HTTP requests or a new WebSocket.
• A WebSocket connection maintains its own namespace and database scope for that connection’s lifetime.
• Live queries require the persistent WebSocket transport; a plain HTTP query cannot maintain the live subscription.
• The same JWT can authenticate both transports while it remains valid and the associated permissions remain sufficient.

Likely explanation

If the socket authenticates successfully but LIVE fails because a namespace or database is missing, the likely cause is an unscoped WebSocket rather than a failed HTTP login. If explicit scope selection still fails, the relevant branches are token validity or permissions, and SDK/server protocol compatibility—not reuse of HTTP session state.

Required connection sequence

HTTP request: authenticate JWT + specify scope -> receive request result
WebSocket: connect -> authenticate JWT -> select namespace/database -> issue LIVE query -> receive events

1. Open the WebSocket using the server’s RPC endpoint and a release-compatible client SDK.
2. Authenticate that socket with the existing JWT through the SDK’s token-authentication operation; repeating username/password sign-in is unnecessary.
3. Select the namespace and database on the same socket.
4. Issue the live query after authentication and scope selection have completed.
5. On reconnect, repeat both steps. Treat token expiry and permission changes as possible reconnect concerns, with exact enforcement timing dependent on the release.

Do not rely on an HTTP sign-in response, cookie, or earlier request to initialize the socket. Even if the JWT contains namespace or database claims, explicitly setting and verifying the WebSocket scope avoids depending on release-specific claim handling.

Version assumption and scoped verification

This explanation assumes the established SurrealDB 2.x session model and a compatible SDK. Header names, RPC method names, and SDK call signatures vary, so check the running server’s version-specific protocol documentation before copying wire examples. This is not a live test of your deployment.

On a non-production namespace and database, make two WebSocket attempts. First, authenticate and issue a live query without scope selection, recording the result. Second, select scope on that connection and issue the live query again, then confirm that a controlled test event arrives. Separately, run an HTTP query with the same JWT and explicit scope to validate token and permissions independently.

If the second attempt still fails, the exact server error is the one diagnostic detail that changes the next recommendation: it distinguishes scope, token, and protocol failures.