Authentication flow

At launch the CLI POSTs credentials to the control plane's /login endpoint. On success it receives access_token (short-lived), refresh_token, session_token, and expiry timestamps. Every subsequent request sends the access_token as a Bearer header.

Category: authentication

Description

## Overview The CLI authenticates once per process against the control plane and then uses the issued tokens for every subsequent request. There is no on-disk token cache; each new `delta-forge-cli` invocation starts with a fresh login handshake. ## Behavior - The initial handshake is `POST /api/v1/login` with a JSON body containing `username` and `password`. A successful response returns `access_token`, optional `session_token`, optional `refresh_token`, plus `expires_in`, `subject_id`, `principal_type`, and optional `session_expires_at` and `name`. - The returned tokens are stored only in process memory on the client. The `CliConfig` also keeps the username and password in memory, so refresh failures can transparently fall back to a full re-login without prompting the user again. - Every authenticated request runs through `ensure_authenticated`, which checks the session and access token deadlines before the call. If the session token is approaching expiry it is refreshed via `POST /api/v1/sessions/refresh`. If the access token is approaching expiry it is refreshed via `POST /api/v1/auth/token` with `grant_type=refresh_token`. If both refreshes fail, the CLI re-runs the original password login. - Control plane API calls send the access token as `Authorization: Bearer <access_token>`. Compute node calls prefer the session token and fall back to the access token when no session is available. - Credentials are resolved in this order: `--username` / `--password` flags, then `DF_USERNAME` / `DF_PASSWORD` environment variables, then the active profile, then the built-in defaults (`admin` / `admin123`). When stdin is a TTY and no explicit credentials were provided, the inline or TUI prompt collects them before login. ## Compatibility - The flow works against any control plane that implements `/api/v1/login`, `/api/v1/auth/token`, and `/api/v1/sessions/refresh`. Control planes that issue only an access token (no session, no refresh) are supported; the CLI simply skips the session and refresh code paths.

Examples

delta-forge-cli auth  # prints tokens to stdout
delta-forge-cli --username svc --password $(pass show df)

Pitfalls

See Also

Open in interactive docs →   DeltaForge home →