> ## Documentation Index > Fetch the complete documentation index at: https://docs.tuneplane.ai/llms.txt > Use this file to discover all available pages before exploring further. # Set up sign-in > Local accounts, OIDC single sign-on, social sign-in, and the token kinds the platform issues. ```bash theme={"theme":{"light":"github-light","dark":"github-dark-dimmed"}} tp admin user-add alice tp login --server https://tuneplane.your-company.com ``` 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: ```bash theme={"theme":{"light":"github-light","dark":"github-dark-dimmed"}} curl https://tuneplane.your-company.com/api/auth/config ``` 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](https://docs.tuneplane.ai/en/ops/roles-and-quotas.md). ## 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: | Provider | Redirect URI | | - | - | | Google | `https:///api/auth/social/google/callback` | | GitHub | `https:///api/auth/social/github/callback` | | Hugging Face | `https:///api/auth/social/huggingface/callback` | > [!WARNING] > > **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: | Token | Issued to | Purpose and boundaries | | - | - | - | | Web session | Browser | Cookie session; with Redis, logout revokes instantly | | CLI access token | `tp login` | API calls; stored in `~/.tuneplane/` (0600) | | Ingest token | Training container | Ingest endpoints only, bound to a single run, limited validity; rejected by the web guard | | MCP OAuth | AI Agent | OAuth 2.1 + PKCE, per-tool authorization | | Share snapshot | Read-only link | Scoped to a single snapshot | ## Check it worked ```bash theme={"theme":{"light":"github-light","dark":"github-dark-dimmed"}} curl https://tuneplane.your-company.com/api/auth/config ``` 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: | Setting | Why | | - | - | | `TUNEPLANE_WEB_JWT_SECRET` | Set it to a fixed strong random string, the same on every replica. The default is generated per process, which logs everyone out on restart and makes a token issued by one replica useless at the next | | `TUNEPLANE_REDIS_URL` | Without it, logging out or disabling an account takes effect at token expiry rather than immediately, and rate limits are per process | 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](https://docs.tuneplane.ai/en/console/audit.md). > [!WARNING] > > `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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.