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.

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.

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.

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.