Skip to content

Search is only available in production builds. Try building and previewing the site to test it out locally.

Identity

Generally Available

Identity is the foundation of Reactor.cloud. Every other capability—Data, Storage, Functions, Jobs, Sites, Gateway, and Connect—builds on the same user, organization, and permission model.

Identity provides email/password authentication, JWT access tokens with rotating refresh tokens, multi-tenant organizations, role-based permissions, and org-scoped API keys. The HTTP surface is GoTrue-shaped so existing client patterns from Supabase and similar platforms transfer directly.

When you send a request to any Reactor API, Identity answers three questions: who is this caller, which organization are they acting in, and what are they allowed to do?

  • Email and password auth — Sign up, sign in, password recovery, and email verification (when SMTP is configured).
  • JWT access tokens — RS256-signed tokens with a one-hour TTL; verified cryptographically without a database roundtrip on the happy path.
  • Rotating refresh tokens — Single-use refresh tokens with theft detection; reusing a burned token revokes the entire session.
  • Multi-tenant organizations — Users belong to one or more orgs; switch context with the X-Reactor-Org header (UUID or slug).
  • Role-based permissions — Built-in owner, admin, and member roles; define custom roles per org with dotted permission strings like data:todos:read.
  • API keys — Opaque service tokens for server-side integrations; revocable and auditable.
  • JWKS endpoint — Standard OpenID discovery and key rotation for third-party JWT verification.

This minimal flow creates a user, signs in, creates an organization, and reads the current profile.

Terminal window
# Sign up
reactor auth signup user@example.com --password 'SecurePass123!'
# Sign in and export token
export REACTOR_TOKEN=$(reactor auth login user@example.com --password 'SecurePass123!' --json | jq -r .access_token)
# Create an organization
reactor auth orgs create acme --name "Acme Inc"
# Get current user
reactor auth user get

Organization owners and admins can invite members by email. When SMTP is configured, Reactor sends the invitation; otherwise you get a shareable signed link for local development.

Terminal window
reactor auth orgs invitations create acme \
--email teammate@example.com \
--role member

Pass the active org on every request that operates on org-scoped resources. Reactor accepts either the org UUID or its slug.

Terminal window
reactor auth orgs use acme
reactor data query todos --limit 5

Create a custom role with scoped permissions

Section titled “Create a custom role with scoped permissions”

Define roles that grant exactly the access your app needs—no more, no less.

-- Permissions are assigned via the API; example permission strings:
-- data:todos:read, data:todos:write, storage:avatars:read, functions:checkout:invoke
Terminal window
reactor auth orgs roles create acme editor \
--permissions 'data:posts:read,data:posts:write,storage:media:read'
reactor auth orgs members update-role acme user_01HZ... --role editor

Add an [identity] section to your project’s reactor.toml. Environment variables override these values at runtime.

[identity]
# Required: 32-byte AES key for encrypting sensitive columns (base64-encoded)
data_key = "base64-32-byte-key-here"
# JWT settings
jwt_issuer = "reactor-auth"
jwt_audience = "reactor"
access_ttl_secs = 3600 # 1 hour
refresh_ttl_secs = 2592000 # 30 days
# Public URL used in email links and invite URLs
public_url = "https://api.reactor.cloud"
# Optional SMTP for verification, recovery, and invite emails
[identity.smtp]
host = "smtp.resend.com"
port = 587
user = "resend"
password = "re_..."
from = "noreply@example.com"
tls = "starttls"
LimitValueNotes
Access token TTL1 hourConfigurable via access_ttl_secs
Refresh token TTL30 daysSliding expiry on each rotation
Password hashingArgon2id64 MiB memory, calibrated per deploy
JWT signingRS256, 2048-bit RSATwo active keys during rotation window
Org slugURL-safe, unique per deployAccept UUID or slug in path params
Session revocation lagUp to 1 hourAccess tokens valid until exp; logout revokes refresh tokens immediately
Rate limitingNot in v0Delegate to reverse proxy or add in v0.2

Built-in role permissions:

RoleDefault permissions
owner* (full access)
admindata:*:*, storage:*:*, functions:*:*, jobs:*:*, auth:members:*, auth:roles:*
memberdata:*:read, storage:*:read, functions:*:invoke

Key endpoints:

MethodPathDescription
POST/auth/v1/signupCreate a new user
POST/auth/v1/token?grant_type=passwordSign in
POST/auth/v1/token?grant_type=refresh_tokenRefresh access token
GET/auth/v1/userCurrent user profile
GET/auth/v1/orgsList user’s organizations
POST/auth/v1/orgsCreate organization
GET/auth/v1/permissionsEffective permissions for active org
GET/auth/v1/keysJWKS for token verification

The email or password does not match, or the account is disabled. Password recovery always returns 204 to prevent email enumeration—check your inbox (and spam) if SMTP is configured.

Terminal window
reactor auth recover user@example.com
reactor auth doctor

403 on Data or Storage despite valid token

Section titled “403 on Data or Storage despite valid token”

Your JWT is valid but the active org lacks permission, or X-Reactor-Org points to an org you are not a member of.

  1. Confirm membership: GET /auth/v1/orgs
  2. Check effective permissions: GET /auth/v1/permissions with X-Reactor-Org set
  3. Ensure the role includes the required permission (e.g. data:todos:write)

If a refresh token is used twice, Reactor revokes the entire session as a theft-detection measure. The user must sign in again. This is expected behavior—do not store refresh tokens in multiple places.

Invites and verification require SMTP. Without it, use the signed invite link returned by the API. Verify [identity.smtp] settings and run reactor auth doctor.