Security and isolation

Chat enforces tenant isolation, token checks and conversation membership on the server, on every call. A user interface can hide controls, but it is never the security boundary. This page lists what Chat guarantees and what remains your responsibility.

What Chat guarantees

Isolation between tenants and applications

The context comes from the URL, and Chat verifies it. The tenant and application are read only from /tenants/{tenant_id}/applications/{application_id}, never from a token claim or a request body. Chat checks them against the Identity Server.
Other tenants’ resources look missing. A conversation or message of another tenant or application answers 404, the same as one that does not exist. Chat never reveals which.
Clients are bound to their context. A machine token, and a user token issued to your tenant application’s own client (including an exchanged one), work only in that tenant and application. Anywhere else answers 403 client_context_mismatch.
Membership is not enough to cross over. A user who belongs to tenants A and B sees tenant B’s Chat data only when they use tenant B’s context.

Access to conversations

Membership is checked on every call. A user reads and writes only in conversations they are a member of, plus PUBLIC channels they can read. Anything else answers 404 or 403 not_conversation_member.
Permissions are checked on every call. A user needs the Chat permission for the operation, in this application. See Chat permissions.
Machines are limited. A backend client acts only within what its scopes carry, and can never delete messages or use Chat Administration. See Machine scopes.
Your backend’s messages are labelled. They carry sender_client_id, so they can be told apart from a user’s own.
Realtime is subscribe-only. A stream covers only the channels the user may read, and Chat recomputes that on every token. See Realtime.

Tokens

Chat verifies the signature, issuer, audience, expiry and scope of every token. It accepts only Authorization: Bearer, and verifies no DPoP proofs.
Tokens are short-lived. A user token lives at most 10 minutes, and a realtime credential at most 10 minutes.
Chat Administration changes can be checked for revocation, and then answer 401 token_revoked.
If Chat cannot reach the Identity Server and has no fresh answer, it answers 503 identity_unavailable instead of guessing. Chat keeps short-lived copies of identity answers, and an administrator can refresh them; see Refresh from the Identity Server.
Error messages never contain tokens or verification details, and Chat does not log tokens, authorization codes or secrets.

Browsers and transport

Origins come from the Identity Server. Chat admits a browser origin on your application’s routes when it is listed in allowed_origins on your application’s SPA client at the Identity Server. Nothing is configured on the Chat side, and a newly added origin works within about a minute. Chat Administration routes never admit tenant origins. Admitted responses carry no credentials, because your app authenticates with a bearer token.
Secrets stay out of browsers. A backend client is a confidential client, and its secret lives on your server only. Browsers hold a user token, and nothing else.
HTTPS only.
Request size. A body larger than 256 kB answers 413 payload_too_large. A body that is not valid JSON answers 400 invalid_json.
Rate limits. Machine clients, sending and lookups are limited, and an excess answers 429. See Limits.

Audit

Management actions are audited and appear in the audit log of Chat Administration: creating, updating and deleting conversations, adding and removing members, deleting a message as a moderator, and administration changes. See Audit log.

What stays with you

Chat cannot take these over, because it knows nothing about your business:

You own	Why
Who may talk to whom	A permission says which kind of operation, never with whom. Check your rules before your backend creates a conversation.
Who your backend acts for	`actor_user_id` is trusted from your backend. Pass the user you authenticated, not a value from the request.
Your backend client’s secret	Keep it in your server’s secret store. Never ship it to a browser or a repository.
The token route	Put your normal access check in front of it, and return a token only to the user it belongs to. Do not log tokens.
Origins	Register your web app’s origin on its SPA client at the Identity Server.
Users and roles	Create and assign them in the Identity Server.