Authentication
How clients authenticate to Rivet: secrets for your backend, short-lived JWTs for public clients, and ACL tokens for long-lived scoped access.
Every request to Rivet carries a credential, and the control plane checks what that credential may reach before routing it to an actor. This page covers the kinds available. To authorize a caller after it is connected, see Permissions.
Authentication is required by default. On a self-hosted control plane, auth.insecure_allow_unauthenticated restores the old unauthenticated behavior for a trusted network; do not enable it on anything publicly reachable.
Choosing a Credential
| Lifetime | Scope | Revoke | Available in | |
|---|---|---|---|---|
| Admin token | Static | Everything, every namespace | Rotate the secret and restart | Self-hosted |
| Secret key | Static | One namespace | Delete the key | Rivet Cloud |
| JWT | 1 hour by default, 24 hour maximum | One namespace, one grant set | Wait for expiry | Self-hosted, Rivet Cloud |
| ACL token | Long-lived | Roles built from reusable policies | Delete the token | Enterprise |
Your backend can hold a secret, so it uses one directly. A browser or mobile app cannot, because anyone can read it out of the bundle, so mint a short-lived JWT per user on your backend and hand that out instead. Reach for ACL when a credential has to outlive a session and stay revocable.
On Rivet Cloud the secret, publishable, and connection keys are created from the dashboard or the CLI. See Tokens.