Have you seen Macaroon Tokens? I've always wanted to use them for authorization processes but haven't had the chance, however they seem like a potential match for your use case.
Here's the research paper and here's a very simple demo tool.
You could for example add several caveats such as client's IP or other similar fingerprint so that a stolen macaroon can't be used elsewhere. Or maybe you can restrict the expiry time to 1 minute or even require a macaroon per request (i.e. chat message or something perhaps?).
Unfortunately for some reason there doesn't seem to be wide adoption of this very cool concept, so a lot of the stuff is old and not sure how maintained the different libraries are, so the usefulness might be limited for you, depending on your case.
However the most common technique I've seen is basically just using cookies (with short expiration times, depending on your use case) to keep server-side session identifiers, which you can use to control access. Just make sure you use HTTPS to send them.
Edit to address the comment:
What I meant by fingerprinting was getting some kind of info from the user (when they login) and adding them as a Macaroon caveat. e.g.
Add a valid email for that "namespace" such that user X in namespace N can't just jump in to namespace M.
Build a whitelist with the known range of IPs for each client that have authorization to access their chat. You can try to determine the IP via WebRTC leak but that requires a browser that supports WebRTC, and the leak might be fixed later on, depending on the browser.
The answer to determining the client's IP will depend on your particular use case. There's lots of different solutions there that have a variable amount of cost/benefit ratio that only you can evaluate.
For example, you could use a Node server, but if you don't have one already, this might be costly in terms of new infrastructure, code, etc. Maybe you have a Tomcat server that you can already use to find the IP and can plug into that, etc. But they all have different security implications and associated costs, so this would be a broad question.
I've also read some comments regarding how insecure JWT's are if you are using them for client-side sessions. So I might add this just in case someone recommends it.
This article: JSON Web Tokens should be avoided spurred some discussion by people that work in the field, for example this comment by Thomas Ptacek.
The issue with JWT in particular is that it doesn't bring anything to
the table, but comes with a whole lot of terrifying complexity. Worse,
you as a developer won't see that complexity: JWT looks like a simple
token with a magic cryptographically-protected bag-of-attributes
interface. The problems are all behind the scenes.