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, DTLS, QUIC, or a private tunnel. Public entrypoints can then add edge authentication, TLS policy, IP restrictions, GeoIP restrictions, and project-wide runtime requirements without asking every upstream service to implement those controls itself.

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, and project-wide policies. The important design point is that security is layered: the private environment initiates outbound connectivity, the engine authenticates runtime clients, and published endpoints can add protocol-specific policy at the edge.

Authentication surfaces

rstream uses bearer tokens for API calls, engine connections, and HTTP tunnel requests protected by token authentication. Tokens are read from the Authorization: Bearer <token> header. When the header is not present, selected browser-facing flows can also use the rstream.token query parameter.

The rstream.token query parameter is URL-visible, so each endpoint restricts what kind of token may be used there. Engine watch endpoints (/api/sse and /api/websocket) accept query tokens only when they are short-lived auth or app tokens with tunnels.resources.read-only and resources.tunnels.scopes.tunnels.list access. Those query tokens must be minted at runtime, especially from browsers where WebSocket and EventSource cannot attach an Authorization header. Do not put durable PATs, application secrets, account sessions, or cookies in engine URLs. Published tunnel endpoints, including published WebTTY, validate the token against that tunnel's own permissions and resources.tunnels boundaries.

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.

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.

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.