Tenant-level only

The playground is an app-tier tool, so it only exercises tenant-level sign-in. Testing your org's own console Okta setup means actually signing in at https://dev-console.nostackai.com with a real teammate account.

The playground app's Settings page has a dedicated section for each provider, so you can complete a real sign-in and confirm token exchange without writing any client code first.

Google (plain Google account)

1First register the same Google client id in the workspace you test against: Tenant Settings → SSO → Google. Without it the token exchange is refused.
2Open Settings and enter your Google OAuth client id in the "Google client id (optional)" field — this is stored locally in your browser only, never sent anywhere but Google.
3A "Sign in with Google" button appears once a client id is set. Click it and complete the Google account picker.
4The returned Google ID token is captured automatically into the oauthtoken field, ready for token exchange.

Google with a company email (Google Workspace)

1In Tenant Settings → SSO → Google, enter the client id and a sign-in domain (for example acme.com), then save.
2In Settings, find "Google with a company email", enter an email at that domain and click "Continue with Google". The playground calls POST /ssoconfig, gets provider: google and the workspace's client id, and shows Google's button for that client id.
3Complete the Google account picker with an account at that domain. The ID token is captured into the oauthtoken field; click Exchange.

Okta (or any tenant-configured OIDC provider)

1Complete Okta for tenants first, including saving the provider — with its Email domain field — under the tenant you're testing against.
2In Settings, find "OAuth / Okta SSO" and enter an email at that domain — the same Email field the Auth & Account section above uses. There's no tenant_code field; it's resolved entirely by the domain.
3Click "Sign in with Okta". The playground calls POST /ssoconfig with that email and its own client_id header, then redirects your whole browser tab to the IdP's authorize endpoint returned in the response.
4Sign in with an Okta user assigned to the app integration, using an account at the same email domain you entered. Okta redirects back with the ID token in the URL fragment.
5On reload, the playground extracts the token from the fragment, checks the state value round-tripped (rejecting it otherwise), strips the fragment from the URL, and captures the token into the oauthtoken field — same as the Google flow.

Completing the sign-in

Either flow leaves you with a raw provider ID token in the oauthtoken field. Trigger the token exchange from there the same way a native login does — the playground calls GET /token with that value as the oauthtoken header and stores the resulting x-nostackai-token for every subsequent call.

What actually differs between the two, under the hood

Every sign-in token is verified before an app JWT is minted. A Google token is checked against Google's published keys and must have been issued to a client id a workspace registered; an Okta (or other tenant-configured OIDC) token is checked against that tenant's own okta_jwks_uri, issuer and expiry. A tampered, wrong-issuer or wrong-client token is rejected at that step.

Things worth deliberately breaking

  • Sign in, then edit one character of the captured id_token before exchanging it — the exchange should fail, not silently succeed.
  • Save a tenant SSO provider with an issuer that doesn't match the token's real issuer, then sign in — same expectation.
  • Call POST /ssoconfig with an email whose domain no tenant has registered — expect a 404, not a guess at which tenant you meant.
  • Call POST /ssoconfig with a missing or wrong client_id header — expect a 400/403, not a silent pass-through.
  • Try registering the same email domain on a second tenant in the same org — expect a 409 on save, not two tenants silently sharing a domain.
  • Try the app-tier Invite a Tenant User endpoint as a non-admin member of the tenant — expect a 403, not a silently-accepted invite.

The full scripted checklist for all of this — native identity, both OAuth providers, profile, tenant creation/join, invites, and file uploads — lives in the App User Auth QA sweep the platform team runs before each release.

SSO overview

Org-level vs tenant-level SSO.

App user authentication

The full sign-in and token-exchange picture.