Signing in, and signing a machine out

orca signs in by the device authorization grant: the terminal prints a short code, a browser — possibly on another machine entirely — approves it, and the terminal finds out by polling.

Nothing types a password into a process that could be recording it, and signing in over SSH works exactly the same as signing in locally.

orca auth login

The sign-in outlives the window it was made in

The CLI asks for offline access, which is what lets a tool run from cron without somebody approving a code every hour. The consequence is the reason this page exists: a terminal you signed in from three months ago is still signed in, whether or not you still have that machine.

Integrations → CLI lists them, one row per terminal.

What each row can and cannot say

| Shown | Where it comes from | | --- | --- | | Whether the session is live | The identity server. It decides, always | | When it signed in | The identity server | | Which machine, and which orca | The terminal, which announces both on requests it was making anyway | | When it last ran a command | orcakey.sh’s own record |

A machine name is a claim the client makes about itself. It is there so you recognise your own laptop in a list; nothing is authorised by it, and a terminal running a version of orca from before this existed says nothing at all and is listed as an unnamed machine rather than left out.

Last used is orcakey.sh’s own record rather than the identity server’s, and the two differ in a way that matters: the identity server’s clock moves when a token is renewed, not when somebody runs a command, so a terminal refreshing hourly would read as idle for an hour after doing something.

Revoking ends it in two places

Revoking a session:

1. ends it at the identity server, so the credential on that machine can no longer be exchanged for a new one; and
2. marks it here, so the token already in that terminal’s hand is refused on its very next command — not when it happens to expire.

That terminal is then told what happened, rather than given a bare authentication error:

$ orca env list
This CLI sign-in was revoked from orcakey.sh. Run `orca auth login` to sign in again.

Signing in again from that same machine works immediately. Revoking cuts off a credential, never a person or a machine.

What it does not touch

Your browser sign-in, any other terminal, and any service token. Each is its own credential with its own screen.

Who can revoke what

• Anybody can see and revoke the terminals they signed in from — including a Viewer. Cutting off a laptop you no longer have is taking a credential away rather than being granted one, and a stolen machine should not wait for somebody else to wake up.
• Owners and Admins additionally see and revoke every CLI session in the organisation, which is the other half of removing somebody’s access.

When the list says it cannot tell you

orcakey.sh reads sessions from the identity server, so when it cannot reach it — or when a deployment has not been given a credential for its administrative API — the page says exactly that.

It deliberately does not show an empty list. “Nobody is signed in” and “we cannot see who is signed in” are opposite facts, and the second one is the one worth knowing. Nobody is signed out by it; orcakey.sh simply cannot read the list.