Deployed environments and origins
AUTH4D-30 adds no routes. It fixes the origins at which the API, console and site are deployed, and the issuer that tokens carry in each environment.
| Environment | API and hosted login | Console | Site | Tenant issuer |
|---|---|---|---|---|
| Staging | https://auth.staging.auth4.dev |
https://app.staging.auth4.dev |
https://staging.auth4.dev |
https://auth.staging.auth4.dev/t/{tenantId} |
| Production | https://auth.auth4.dev |
https://app.auth4.dev |
https://auth4.dev |
https://auth.auth4.dev/t/{tenantId} |
Tokens issued in staging never validate in production, and the reverse: the issuers differ, and each environment has its own signing keys, D1 database, Durable Object namespaces, queues and secrets.
Both environments are served only from these custom domains over HTTPS, and the API sends
Strict-Transport-Security. Discovery is at {issuer}/.well-known/openid-configuration and JWKS
is at {issuer}/.well-known/jwks.json. Monitoring uses GET /health and GET /ready on the API
origin; /ready returns 503 when bindings or origins are misconfigured.
Applications should configure the issuer for their environment explicitly. Do not derive it from request headers.
Source: docs/api-spec/auth4d-30.md