This signs in your team, not your app's end-users

This page is for org admins, developers and platform admins signing in to build — API Studio, Tenant Management, billing. For your app's own end-users, see Okta / Auth0 for tenants.

Every org has its own identity domain, so each org registers its own app under Org Settings → Console SSO — there's no shared, platform-wide config the way Google's console sign-in is nostackai's own setup. This flow uses authorization-code + PKCE, and — unlike the tenant-level implicit flow — the browser itself makes a direct call to your IdP's token endpoint to finish signing in, which is why an origin-allowlist step below is required here and isn't for tenants.

Use https://dev-console.nostackai.com, not nostackai.com

The console you and your team sign in to is https://dev-console.nostackai.com — a different domain from nostackai.com itself, which is the marketing site and has no sign-in page at all. Every URL below uses the real console domain; double-check any existing setup that predates this against it.

Option A — Okta

1In your Okta admin console, go to Applications → Applications → Create App Integration.
2Choose "OIDC — OpenID Connect" and application type "Web Application" (this exchanges an authorization code server-side via PKCE — not the browser-only implicit flow the tenant-side setup uses).
3Under Sign-in redirect URIs, add https://dev-console.nostackai.com/auth/callback/okta.
4Under Sign-out redirect URIs, add https://dev-console.nostackai.com/login.
5Save, then copy the Client ID from the General tab.
6Separately — this is NOT part of the app integration — go to Security → API → Trusted Origins and add https://dev-console.nostackai.com, checking both the CORS and Redirect type boxes.

Trusted Origins is a separate, global Okta setting

It's easy to configure the app integration perfectly and still have sign-in fail, because Trusted Origins lives entirely outside the app integration screen — it's an org-wide allowlist under Security → API. Without https://dev-console.nostackai.com listed there (CORS type checked), the browser's direct fetch() to Okta's token endpoint during PKCE exchange fails with a CORS error, even though the redirect itself worked fine.

Option B — Auth0

1In your Auth0 dashboard, go to Applications → Applications → Create Application, name it, and choose "Regular Web Application" or "Single Page Web Application" — either works for PKCE, then Create.
2On the application's Settings tab, set Allowed Callback URLs to https://dev-console.nostackai.com/auth/callback/okta.
3Set Allowed Logout URLs to https://dev-console.nostackai.com/login.
4Set Allowed Web Origins to https://dev-console.nostackai.com — the bare origin, no path. This is the field that's easy to miss since neither of the two above covers it.
5Save Changes, then copy the Domain and Client ID from the top of the Settings tab.
6Check the Connections tab has at least one connection enabled for this application — a new application sometimes starts with none, which silently blocks every sign-in with no error on Settings.

Allowed Web Origins is not optional here

Callback and Logout URLs cover the redirect legs of the flow. Neither covers the browser's own direct fetch() to Auth0's token endpoint during PKCE code exchange — that's what Allowed Web Origins is for. Leave it unset and the redirect to Auth0 works fine, the user authenticates fine, and then the token exchange fails with a CORS error on the very last step — a confusing place to discover a missing setting.

Collect the provider's discovery values

Fetch your authorization server's discovery document to get the exact URLs the next step needs:

text 
Okta:  https://{yourOktaDomain}/oauth2/default/.well-known/openid-configuration
Auth0: https://{yourAuth0Domain}/.well-known/openid-configuration

Copy issuer, authorization_endpoint, token_endpoint, and jwks_uri from that document.

Register it under Org Settings → Console SSO

json 
{
  "okta_issuer": "<issuer from the discovery document>",
  "okta_auth_endpoint": "<authorization_endpoint>",
  "okta_token_endpoint": "<token_endpoint>",
  "okta_jwks_uri": "<jwks_uri>",
  "okta_client_id": "<client id from your app integration>",
  "okta_email_domain": "yourcompany.com",
  "okta_scopes": "openid email profile"
}

okta_email_domain is what makes sign-in findable

Before your team even has a token, the console has to work out which org's app to redirect to — it does that by looking up the email domain the person typed against every org's saved okta_email_domain. Get this wrong (or leave it off) and your team's sign-in can't be found at login time, even though the rest of the config is correct.

How sign-in works after setup

1A teammate enters their work email on the console sign-in page.
2The console looks up the org registered for that email's domain and redirects to that org's authorize endpoint (authorization-code + PKCE — there's no client secret exposed to the browser).
3Your IdP redirects back with a code; the browser itself — not a nostackai backend — exchanges it for tokens via a direct fetch() to token_endpoint. This is exactly the step that needs Trusted Origins (Okta) or Allowed Web Origins (Auth0).
4The ID token's signature is verified against okta_jwks_uri, matched to the org by okta_issuer, before a console session is issued.

Okta / Auth0 for tenants

The separate, per-tenant setup for your app's own end-users.

SSO overview

Org-level vs tenant-level SSO.