# Auth
`openlatch-provider login` runs the same PKCE + browser-loopback flow
as `openlatch-client`. The token (an editor API key shaped
`olk_edt_live_...`) is stored in your OS keyring with an encrypted-file
fallback for headless Linux.
## Login flow
```bash
openlatch-provider login
```
1. Generates a PKCE `code_verifier` + SHA-256 `code_challenge`.
2. Binds a one-shot HTTP listener on `127.0.0.1:0` (OS-assigned port).
3. Opens `https://app.openlatch.ai/cli-auth?...` in your browser.
4. After you approve, the platform redirects to the loopback URL with
a one-time code; the CLI exchanges the code for an editor token.
5. Stores the token in:
- macOS Keychain (`apple-native`)
- Windows Credential Manager (`windows-native`)
- Linux Secret Service (`sync-secret-service`)
- or, on headless Linux, an AES-256-GCM file at
`~/.openlatch/provider/auth.toml` (HKDF-SHA256 over the persistent
`machine_id`, mode 0600).
## Service prefixes
| Keyring | `openlatch-provider` | `editor-token` |
| File fallback | (n/a) | `~/.openlatch/provider/auth.toml` |
## Logout
```bash
openlatch-provider logout
```
Revokes the token server-side via `DELETE /api/v1/api-keys/self` and
clears the local entry.
## CI / non-interactive
Two env-var paths bypass the keyring:
- `OPENLATCH_TOKEN=olk_edt_live_...` — short-lived per-invocation.
- `--token-file /path/to/file` — file-based for orchestrators that
rotate tokens.
Tokens NEVER come in via a CLI flag (`--token=...`) — that leaks the
secret to `ps` and shell history. The CLI explicitly refuses.
## Profiles
`~/.openlatch/provider/config.toml` supports multiple named profiles:
```toml
[profiles.default]
manifest_slug = "my-editor"
[profiles.staging]
manifest_slug = "my-editor-staging"
```
Activate with `--profile staging` or by setting
`OPENLATCH_PROVIDER_PROFILE=staging`.
## Refresh
Tokens issued by the platform have a long expiry (typically 1 year).
`openlatch-provider whoami` validates the token against the platform
on every call; an expired token surfaces `OL-4200`.
## Known issues
- **Linux + no Secret Service**: install `gnome-keyring` /
`kwallet-pam` for the keyring path, or accept the encrypted-file
fallback (it derives the key from `machine_id`, so the file is
bound to the host).
- **Windows + Service accounts**: the Credential Manager backend
only sees the running user's vault. For service accounts, set
`OPENLATCH_TOKEN` in the service's environment and skip `login`.