SpinneryDocs
Browse documentation

Docs / Auth0 and authorization

Auth0 identifies the user; Spinnery authorizes product work.

Use Auth0 for identity and organization login context, then let the Spinnery backend mirror users and organizations and enforce product permissions for every dashboard, CLI, and gateway action.

Review access modelReview security model
identity setupproduct authz

tenantdev-towi6qrmubkmo0d6.us.auth0.com

audiencehttps://api.spinnery.dev

apps: Web App / CLI / Gateway

roles: owner / admin / developer / viewer / billing

authorization: Spinnery backend

Setup anchors

Auth0 configuration stays focused on identity.

The Auth0 side should identify the user, tenant, organization login context, application surface, and API audience. Product permissions remain an Spinnery backend responsibility.

Tenantdev-towi6qrmubkmo0d6.us.auth0.com

All Spinnery identity flows should use this Auth0 tenant for user authentication and organization login context.

API audiencehttps://api.spinnery.dev

Tokens for Spinnery product APIs should target this Auth0 API identifier before requests reach the backend.

ApplicationsWeb App / CLI / Gateway

Keep Auth0 clients separated by product surface so dashboard, terminal, and gateway sessions can be reasoned about independently.

Authorization ownerSpinnery backend

Auth0 proves who signed in. Spinnery mirrors users and organizations, then decides which product actions are allowed.

Auth0 applications

Each app maps to a product surface.

Spinnery Web App, Spinnery CLI, and Spinnery Gateway all start from Auth0 identity, but the backend still decides what that signed-in identity may do inside the product.

Auth0 appAuth0 ownsSpinnery checks
Spinnery Web App

Browser login for the dashboard against the Spinnery Auth0 tenant and API audience.

Checks mirrored user, organization, product role, project access, and billing permission before dashboard actions.

Spinnery CLI

Terminal sign-in for spin login using the same identity and organization login context.

Issues a CLI session only after the backend authorizes organization membership and workspace permissions.

Spinnery Gateway

Gateway application for authenticated product and gateway session handoff.

Enforces workspace, service, signed dev link, and role checks before forwarding to product or runtime surfaces.

Identity handoff

Authentication becomes authorization in the backend.

Treat Auth0 as the source of identity and login context, not the product permission engine. The backend should check the mirrored Spinnery user and organization on every product request.

request pathidentity to permission
  1. AuthenticateAuth0 tenant + audience

    Auth0 proves identity and login context.

    The user signs in through the Spinnery Auth0 tenant, with the requested organization context and API audience attached to the product session.

  2. MirrorAuth0 subject -> Spinnery user

    Spinnery keeps a product record.

    The backend mirrors the Auth0 user and organization into Spinnery records so authorization can be checked and recorded inside the product model.

  3. Authorizeowner/admin/developer/viewer/billing

    Roles decide product actions.

    Every dashboard, CLI, and gateway request is checked against Spinnery product roles plus project, workspace, billing, and dev-link permissions.

  4. Open surfacedashboard / CLI / gateway

    The allowed surface opens.

    Spinnery opens only the authorized product surface. Identity alone does not grant shell, runtime admin, secrets, billing, or signed dev link control.

Product roles

Spinnery roles are product permissions, not Auth0 app names.

Keep the role vocabulary in Spinnery so permissions stay tied to product behavior: organization management, project work, workspace access, dev link sharing, billing, and read-only review.

ownerOrg ownership

Controls organization-level authority, owner assignment, high-risk policies, billing authority, and final permission changes.

adminOrg operations

Manages projects, members, workspace policies, signed dev link controls, and normal organization settings.

developerWorkspace work

Opens workspaces, runs spin up, creates authorized dev links, and inspects runtime readiness for assigned projects.

viewerRead-only access

Reads projects, workspace state, usage, docs, and approved signed dev links without changing product configuration.

billingSpend controls

Manages plan, payment, usage caps, and invoices without inheriting broad code or workspace administration.