Skip to content

← Back to standards

Auth0

Auth0 is how we handle login and API authorization for many Brytebridge products—who the user is and whether the API should trust their token.

APIs on Fly still use Cloudflare and Fly tunnel for network access; Auth0 answers identity: valid user, right audience, right permissions.

What we use Auth0 for

Section titled “What we use Auth0 for”
UsePlain English
User sign-inPortals and apps where people log in with username/password or SSO
API protectionBearer tokens on API routes—validate JWTs against Auth0
Management APISome services create or look up users via Auth0’s management API (separate client credentials)

Not every API uses Auth0—check each repo’s .env.example. When Auth0 is present, secrets live on Fly (per app / tier), not in GitHub for routine deploy.

Typical Fly secrets (per repo)

Section titled “Typical Fly secrets (per repo)”

Names vary by project; common patterns:

SecretPurpose
AUTH0_DOMAINAuth0 tenant hostname
AUTH0_AUDIENCEAPI identifier the token must be for
AUTH0_CLIENT_ID / AUTH0_CLIENT_SECRETApplication client (when the API acts as a client)
AUTH0_MANAGEMENT_CLIENT_ID / AUTH0_MANAGEMENT_CLIENT_SECRETManagement API access
AUTH0_CONNECTIONDatabase / connection name for username-password flows

Set with fly secrets set on each tier’s app—same as other runtime secrets on the Fly checklist.

Environments

Section titled “Environments”
  • Staging, UAT, and production should use separate Auth0 applications or tenants where policy requires it—do not point staging at production identity by mistake.
  • Align Auth0 app names and callbacks with Naming conventions (repo name, tier).

Rotation and ownership

Section titled “Rotation and ownership”

Auth0 client secrets and management credentials are on the Rotation inventory—priority and schedule TBD. Rotating Auth0 secrets requires coordinating Fly redeploy and any front-end client IDs configured in admin apps.

Section titled “Related”