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 grants, 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, the engine also accepts the rstream.token query parameter for tunnel and streaming flows that cannot set headers easily.

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 both surfaces, but the enforcement points are different. Control plane permissions are checked by the hosted API. Tunnel permissions and tunnel grants 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.

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.

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 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.

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 tunnel permissions and tunnel grants control runtime 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.

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 protocols. It is a TLS handshake policy for edge-terminated published surfaces, including HTTP over TLS and non-HTTP TLS, DTLS, or QUIC surfaces where the edge terminates the connection. TLS passthrough is different: the edge does not terminate the TLS session, so certificate validation and TLS policy belong 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 tunnel grants. Community Edition deployments use the local engine authentication backend and do not enforce the managed fine-grained tunnel grants model. Enterprise deployments can integrate the engine with the managed credential schema and enforce the same runtime authorization model.