Skip to main content
Three ways in, and a deployment can run any combination of them. Local accounts work with no configuration: an administrator creates them, users sign in with a username and password. On a fresh deployment the first administrator is created through the console’s first-visit onboarding. OIDC single sign-on is turned on by setting TUNEPLANE_OIDC_ISSUER, TUNEPLANE_OIDC_CLIENT_ID and TUNEPLANE_OIDC_CLIENT_SECRET — Casdoor, Keycloak and anything else that speaks OIDC. The CLI’s browser and device-code logins follow the same flow without extra configuration. Google, GitHub and Hugging Face are configured from the admin settings page and take effect without a restart. Read the warning below before turning one on: with no allow-list, anyone with an account at that provider can create one here. Check which a deployment offers before assuming:

​
Two account systems

Works out of the box: admins create accounts with tp admin user-add, and users log in with username and password. On a fresh deployment, the first administrator is created via the console’s first-visit onboarding (/api/auth/setup).
Two role levels: admin (governance and full visibility) and operator (own projects and jobs).

​
Google, GitHub and Hugging Face sign-in

Configured from Settings → Access → Google / GitHub / Hugging Face sign-in, not from the environment, and live the moment you save — the button appears on the login page with no restart. Nothing is offered until a provider has both its client ID and its secret. Google is genuine OIDC and is discovered from accounts.google.com. GitHub is not OIDC: it publishes no discovery document and issues no ID token, so identity comes from its REST API, and an account whose address is private is read from /user/emails. Hugging Face is OIDC-shaped with fixed endpoints, and its sign-in asks only for identity scopes — separate from the account binding that pulls gated repositories. Register these redirect URIs, one per provider:
An empty allow-list means anyone. With no google_allowed_domains, any Google account on earth can create an account on a console reachable from the internet; the same goes for github_allowed_orgs. Set them, or keep the console off the public internet. New accounts get the role in oidc_default_role.
CLI and device-code logins work through these providers too, so tp login needs no separate configuration. Google One Tap is off by default and switched on separately, because the prompt appears without the visitor asking for it. While it is off, Google’s script is never loaded and the endpoints behind it are closed. The prompt and the button end in the same session, so a visitor who dismisses it loses nothing. One Tap is the only sign-in path where the browser hands the console a token instead of the console fetching one, so it carries two checks the redirect flows do not need: the credential’s signature is verified against Google’s published keys and must name this console’s own client ID, and it must carry a single-use nonce this console issued. Without the nonce a credential that leaked anywhere within its hour of validity could be exchanged for a session.

​
Token system

The platform issues domain-isolated tokens per purpose — no token can impersonate another kind:

​
Security baseline

  • TUNEPLANE_WEB_JWT_SECRET must be set to a fixed strong random string (identical across replicas);
  • Configure TUNEPLANE_REDIS_URL in production: instant token revocation on logout / ban, distributed rate limiting;
  • Cluster and storage credentials stay server-side only; the job side sees only presigned URLs and run-scoped ingest tokens;
  • CLI packaging has a sensitive-file blocklist (.env, *.pem, id_rsa*…), so secrets never end up inside job packages;
  • All sensitive operations enter the audit trail.
TUNEPLANE_NO_AUTH=1 is for local development only: it skips all authentication and makes everyone admin. Never enable it in any multi-user environment.