Environments & base URLs
Your credentials belong to exactly one environment, and every URL you use follows from that. This page is the whole answer — you should never need to guess a host, read our source, or infer where a feature is deployed.
issuer and the iss claim on every token it signs — one value, not three, and the service refuses to start if anything contradicts it. Resolve every endpoint from the discovery document at that origin rather than building URLs by hand.The environments
| Environment | Base URL (= issuer) | Who can reach it | Sign in with authreads |
|---|---|---|---|
| dev | http://127.0.0.1:3020 | Localhost only — dev is a developer's own machine. There is no shared dev server and no dev DNS name, so dev credentials are usable only by someone running the stack locally. | Available — Discovery, /oauth/authorize, /oauth/token, /oauth/userinfo, revoke and logout all respond, and the discovery document is spec-conformant. |
| beta | — | Nothing is deployed under this name. This is authreads' own deployment environment — a hosted tier of the auth platform itself, distinct from any "beta"/"staging" label you give your own product's tiers (see the callout below the table). No host, DNS name or listener exists for an authreads beta. | Not available — There is no beta environment to reach. Beta credentials should not be issued yet. |
| prod | https://api.authreads.com | The internet. This is the environment your production integration targets. | Available — /.well-known/openid-configuration returns 200 with a complete, spec-conformant document (issuer, token endpoint, JWKS URI, grant types). Every deploy re-verifies this and hard-fails the release if it regresses, so it can be relied on as always-on. /.well-known/oauth-authorization-server (the OAuth 2.0 Authorization Server Metadata document, RFC 8414) is a separate, optional document and genuinely returns 404 — use OIDC discovery instead, not that path. |
Reviewed 2026-08-26. Availability can change without this page changing on the same day, so confirm anything you are planning a go-live date around with your onboarding contact.
environment label you define yourself (for example production or beta as a tier of your own product) — that label is not one of these three, and authreads never routes on it. Unless you were explicitly given a dedicated non-production authreads environment during onboarding, every tier of your own product — whatever you call it — authenticates against and receives tokens issued by authreads prod. If you maintain an issuer allowlist keyed by your own environment names, every one of them needs the prodissuer above, including a tier you call “beta”.Check it yourself, in one request
Discovery is the single request that tells you whether the OIDC provider is deployed and usable at a given origin. If it returns a document, the provider is there; if it 404s, it is not.
curl -fsS "$BASE/.well-known/openid-configuration"/.well-known/jwks.json as the test. That endpoint is older than our OIDC provider, so it answers 200 even where discovery, /oauth/authorize and /oauth/userinfo do not exist. One endpoint responding is not evidence a feature is deployed — this exact trap cost a real integration an afternoon.The document you get back is guaranteed self-consistent: its issuer equals the origin you fetched it from, as OpenID Connect Discovery 1.0 §4.3 requires, and every endpoint it advertises is on that same origin. A conformant client library can consume it with no special configuration.
If you were issued dev credentials
Dev is a local machine, not a hosted environment you can call. There is no shared dev server and no dev hostname, so dev credentials only work against a stack running on that machine. If you need a non-production environment you can reach over the network, say so during onboarding — it is an environment that has to be stood up, not a URL that exists and is undocumented.
127.0.0.1 and localhost are not interchangeable here. The issuer is compared as an exact string, and the dev base URL above is published as http://127.0.0.1:3020 — not http://localhost:3020. They're the same machine and different issuer strings; a token issued with one never verifies against an allowlist that only has the other. Whatever your local stack actually binds and advertises as its base URL is the value to put in your issuer allowlist — copy it from the discovery document's own issuer field rather than typing either form from memory.