EFEnvForgeJoin waitlist

Docs / Auth0 and authorization

Auth0 identifies the user; EnvForge authorizes product work.

Use Auth0 for identity and organization login context, then let the EnvForge 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.envforge.ai

apps: Web App / CLI / Gateway

roles: owner / admin / developer / viewer / billing

authorization: EnvForge 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 EnvForge backend responsibility.

Tenantdev-towi6qrmubkmo0d6.us.auth0.com

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

API audiencehttps://api.envforge.ai

Tokens for EnvForge 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 ownerEnvForge backend

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

Auth0 applications

Each app maps to a product surface.

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

Auth0 appAuth0 ownsEnvForge checks
EnvForge Web App

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

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

EnvForge CLI

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

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

EnvForge 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 EnvForge 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 EnvForge Auth0 tenant, with the requested organization context and API audience attached to the product session.

  2. MirrorAuth0 subject -> EnvForge user

    EnvForge keeps a product record.

    The backend mirrors the Auth0 user and organization into EnvForge records so authorization can be audited and enforced inside the product model.

  3. Authorizeowner/admin/developer/viewer/billing

    Roles decide product actions.

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

  4. Open surfacedashboard / CLI / gateway

    The allowed surface opens.

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

Product roles

EnvForge roles are product permissions, not Auth0 app names.

Keep the role vocabulary in EnvForge 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 envforge 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.