Skip to main content
Three ways to authenticate a machine, from most to least interactive.

​
1. Device flow: orca login

On a terminal with no usable browser (a coding agent, SSH, a container), orca login runs an RFC 8628 device flow automatically:
Open the URL on any device, sign in, check the code matches, and approve. The CLI receives its key by polling and stores it in ~/.config/orca/config.json; the key never appears on a screen or in a paste buffer. Force this flow anywhere with --headless. Security shape worth knowing: the minted key inherits the approving user’s role, the approval screen shows which terminal asked (the key label, for example claude-code-ada@laptop), and codes are single-use with a 15 minute expiry.

​
2. Environment variables

For processes that should never prompt:
Both the CLI and the MCP server read these before falling back to the config file. Mint keys in the dashboard (Settings, then API Keys) or from an already-authenticated CLI:

​
3. Pre-minted token

Verifies the key and persists it into the current context; useful when a human minted the key elsewhere.

​
Verify

Returns the tenant, role, credential kind, and key id the stored credential acts as.

​
Honest caveat: keys have no scopes

An Orca API key carries exactly one authorization dimension: the RBAC role it inherited from whoever minted or approved it (owner, admin, member, or viewer). There are no per-resource or per-operation scopes yet. Treat an admin key as admin everywhere; prefer approving device logins from a member account when the agent only needs day-to-day operations, and revoke keys you stop using (orca auth logout --revoke, or the dashboard key list).
The full guide to login flows, the config file, contexts, and precedence is Authentication and contexts.

​
Next

Once the session is signed in, Build it with your coding agent is what it does next, from the first ask through to an agent whose output holds three runs in a row.
Last modified on September 6, 2026