Security Model

rstream security starts with the network shape. Services do not need inbound ports, public IP addresses, or direct exposure from the private environment. Agents and SDKs initiate outbound-only sessions to the engine, and the edge becomes the single place where identity, policy, and protocol-specific access rules are applied before traffic reaches upstream services.

The client-to-engine layer is always encrypted and authenticated. It carries tunnel control operations and upstream traffic over a unified rstream protocol, regardless of whether the published workload is HTTP, TLS, TCP, DTLS, QUIC, or a private tunnel. Public entrypoints can then apply the controls available to their protocol, including project policy, IP restrictions, GeoIP restrictions, edge authentication, and TLS policy. A raw TCP endpoint does not add downstream encryption or authentication; the application protocol must provide those properties where required.

Authentication answers who is allowed to use the platform and the tunnel runtime. Authorization then narrows what that identity can do: which APIs it can call, which projects it can use, which tunnels it can create or connect to, and which HTTP paths or tunnel properties are allowed.

This page is the entrypoint for the security section. It explains where security controls are enforced before the dedicated pages describe token formats, delegated resources, project-wide policies, and client-held encryption keys. The important design point is that security is layered: the private environment initiates outbound connectivity, the engine authenticates runtime clients, published endpoints can add protocol-specific policy at the edge, and selected protected data can add client-side encryption.

Authentication surfaces

rstream uses bearer tokens for API calls, engine connections, and HTTP tunnel requests protected by token authentication. The canonical transport is the Authorization: Bearer <token> header. Selected browser-facing flows also accept rstream.token in the query string because browser EventSource, browser WebSocket, and a few protocol clients cannot always attach custom headers.

The query-string path is an endpoint-specific fallback, not a second general-purpose credential channel. The same parameter name can appear on an engine watch URL and on a published tunnel URL, but the token is validated by different enforcement points:

• engine watch endpoints (/api/sse and /api/websocket) accept only short-lived watch tokens that can list live resources and cannot create or connect to tunnels;
• published tunnel endpoints, including published WebTTY, validate connect tokens against the target tunnel, request path, and resources.tunnels boundary;
• producer and agent runtimes normally use headers or SDK configuration, and their tokens are scoped to tunnel creation rather than browser traffic.

Do not put durable PATs, application secrets, account sessions, or cookies in URLs. Browser-facing backends should mint narrow runtime tokens on demand, then let those tokens expire quickly. The detailed watch-token rules are documented in Signaling, and published HTTP tunnel token authentication is documented in HTTP tunnel authentication.

Authentication covers two surfaces. Control plane APIs are the hosted APIs used to manage accounts, workspaces, projects, credentials, billing, TURN credentials, logs, and rstream Auth requests. Engine operations are the tunnel runtime operations used to create tunnels, open connections, list live tunnel state, and authorize HTTP requests at the edge.

The same token can carry permissions for several surfaces, but the enforcement points are different. Control plane API permissions are checked by the hosted API. Engine API permissions and resources.tunnels boundaries are checked by the engine when a client creates a tunnel, connects to a tunnel, lists live resources, or sends an HTTP request through a protected published tunnel. TURN runtime permissions are checked by the TURN service when a client allocates relay traffic.

Token families

rstream uses three token families. Personal access tokens are long-lived credentials created from the Dashboard or API. Application credentials contain a client id and client secret; they are intended for backend services that mint short-lived application tokens locally. Auth tokens are short-lived tokens created by API calls and are typically used for delegation to a browser, device, worker, or another service.

Token behavior is detailed in Tokens. Fine-grained tunnel restrictions are detailed in Fine-grained tokens. Client certificate authentication is detailed in mTLS.

How the pieces fit together

Use Tokens to choose the credential family and understand permission reduction. Use Fine-grained tokens when a backend must delegate a narrower tunnel capability to a browser, device, worker, or tenant. Use mTLS when runtime authentication should be bound to client certificates. Use Access policies for project-wide runtime requirements that should apply even when a token would otherwise allow an operation. Use Workspace Protection and Encryption Model when protected workspace data or WebTTY terminal content must remain decryptable only from trusted clients.

HTTP tunnels

Published HTTP tunnels can enforce authentication before traffic reaches the upstream service. Token authentication accepts rstream tokens on each request. rstream Auth adds a browser-oriented session flow for interactive users. mTLS authenticates clients with certificates during the TLS handshake.

This edge enforcement is documented in HTTP tunnel authentication. That page uses the same token model described here: API permissions control access to platform APIs, while runtime permissions and resources.tunnels boundaries control access enforced by the engine.

Private access

Private tunnels are not exposed through a public hostname or public socket. They are dialed by rstream clients using a tunnel id or name, and both the publisher and the dialer establish authenticated outbound sessions to the engine.

This makes private tunnels the natural default for service-to-service paths, administrative access, SSH workflows, and internal tools that do not need standard Internet clients. The model is documented in Private Tunnels.

Transport security

Communication between rstream clients and the engine is protected with TLS 1.3.

Published tunnels can accept TLS 1.2 or TLS 1.3 depending on the tunnel configuration. Managed projects default to allowing TLS 1.2 and TLS 1.3 for published traffic, and the minimum version can be raised to TLS 1.3 per tunnel or project-wide through Access policies.

The transport layer can use TLS over TCP or QUIC. That choice changes the client-to-engine network path, not the tunnel policy. QUIC transport, DNS override, DNS over TLS, DNSSEC validation, HTTP CONNECT proxying, and deterministic egress are documented in Tunnel Transports.

References:

TLS 1.2 RFC 5246, TLS 1.3 RFC 8446, QUIC transport RFC 9000, DNS over TLS RFC 7858.

Client-side encryption

Some data needs a stronger boundary than transport encryption. Workspace Protection lets trusted browsers and trusted devices hold private keys locally, while rstream stores only public keys, encrypted key envelopes, signatures, and metadata. WebTTY uses that model for workspace-managed terminal encryption and encrypted recordings.

Workspace Protection requires an Enterprise workspace. WebTTY explicit-key E2E is a separate client/server trust model and does not imply workspace-managed key custody, trusted browser/device approvals, or Recovery Kit recovery.

This is separate from token authorization. A user can be authorized to request protected data and still be unable to decrypt it from an untrusted browser or device.

Edge TLS policy

When the edge terminates TLS, published tunnels can use a minimum TLS version, mTLS, post-quantum key exchange preferences, and Encrypted Client Hello policy where the engine and DNS configuration support them. These controls apply at the edge before traffic is forwarded upstream.

mTLS is not limited to non-HTTP published protocols. It can authenticate agent control-channel connections, and it can also require mTLS for public traffic entering published tunnel endpoints. Those are separate policies: agent authentication protects the engine session, while published Tunnel access protects the public endpoint. The Engine HTTP API is token-authenticated. TLS passthrough is different because the edge does not terminate the TLS session, so certificate validation belongs to the upstream service.

Deployment notes

Managed rstream projects use the hosted credential store for personal access tokens, application credentials, auth tokens, project settings, and resource boundaries. Community Edition deployments use the local engine authentication backend and do not enforce the managed fine-grained resource-boundary model. Private deployments arranged with rstream can integrate the engine with the managed credential schema and enforce the same runtime authorization model.