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:
The first administrator on a fresh deployment is created through the console’s first-visit onboarding, at /api/auth/setup. Three roles: admin, operator and auditor. TUNEPLANE_OIDC_DEFAULT_ROLE decides what a first-time single sign-on login gets. See roles and quotas.

​
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:

​
Check it worked

Lists the sign-in methods this deployment offers. Then sign in once through each one you configured, and check the new account landed with the role you expected.

​
Security baseline

Two settings to get right before going live: Three things you do not have to configure, because they are structural:
  • Cluster and storage credentials stay on the server. A job receives presigned URLs and a run-scoped ingest token, never a key.
  • tp submit refuses to package a file that looks like a credential, so a secret cannot reach a job through the bundle.
  • Every sensitive operation enters 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.