Auth

Kisenon has two ways to authenticate:

Web sign-in — Google or GitHub OAuth via NextAuth on the console.
API key — an nsk_… token that any HTTP client (including keon) can present as a Bearer credential.

The same key can drive the CLI, CI, and one-off curl calls.

Open kisenon.com and click Sign in. Pick Google or GitHub. NextAuth handles the OAuth dance, then exchanges the provider's id token for a control-plane JWT via POST /v1/auth/exchange. That cp-signed JWT is the credential every subsequent console request carries.

The JWT is short-lived — it expires roughly 15 minutes after issue. While you're active, NextAuth refreshes it in the background by re-presenting the current JWT to POST /v1/auth/refresh, which mints a fresh one. The refresh credential is the JWT itself, valid within a 12-hour window from sign-in; once that window lapses, the next request redirects you to sign-in.

Access during alpha

Sign-in is gated. Only emails on the alpha allowlist can complete the exchange — a non-listed account gets a 403 email_not_allowed back from /v1/auth/exchange and never receives a session. Allowlisted accounts that have signed in but aren't yet approved land in a pending state: the console redirects them to /pending, and the control plane answers gated API calls with 403 alpha_pending until an operator approves the account. See Alpha access to apply.

Organizations and roles

Identity is organization-first. Every session carries an active organization and your role in it (for example owner or member); the cp JWT encodes both, and the control plane re-reads your role on each refresh. Personal sign-ups get a personal organization automatically; invited users land in the team organization on first sign-in.

If you belong to more than one organization, the organization switcher in the console (top of the signed-in layout) lists them with a role badge. Picking one POSTs to /api/auth/switch-org, which proxies to cp's /v1/auth/switch-org and splices a fresh JWT — scoped to the new organization — into your session. All console requests after the switch act in the selected organization.

See Organizations for how organizations and roles work, and Invitations for adding teammates.

API keys

API keys are organization-scoped credentials. Each key:

Carries the format nsk_<random> and is shown once at creation.
Is hashed at rest. We cannot recover the plaintext after creation, so save it now or rotate it later.
Belongs to one organization and acts with your identity inside it.
Can be revoked at any time without affecting other keys.

Manage keys at Settings → API keys in the console. Each row shows the key's name, id, the creation date, and when it was last used. Create takes a name and reveals the secret once; revoke and rename are inline.

Scopes and capability

The control plane scopes each key two ways:

Scope kind — org, project, or branch. An organization-scoped key reaches everything in the organization; a project- or branch-scoped key is restricted to the named project(s) or branch, and requests for any other resource get 403 scope_insufficient.
Capability — read or read_write. A read key is refused on any mutating call.

Keys created from the console today are organization-scoped with read_write capability — there is no scope picker in the UI yet. Narrower project/branch scopes and the read capability are available by POSTing a scope and capability to cp's /v1/api-keys/ endpoint directly.

CLI loopback OAuth

keon login does not ask you to paste an API key. Instead it runs a loopback OAuth flow:

The CLI starts a local HTTP listener on a random high port.
It opens your browser to https://kisenon.com/cli/authorize?... with a one-shot state token and the loopback redirect URL.
You sign in (or are already signed in) and click Authorize.
The console redirects to the loopback URL with a short-lived code.
The CLI exchanges the code at POST /v1/cli/exchange for a freshly minted API key.
The key is persisted at ~/.config/keon/credentials.json with mode 0600.

After the flow, keon whoami confirms the key is wired:

keon login
keon whoami

The CLI does not store the OAuth code, the state, or any provider-side token; only the resulting API key. Rotate or revoke that key from the console at any time.

Logout

keon logout revokes the local API key on the server and removes the credentials file. After logout, the same keon login flow mints a new key — old credentials cannot be reactivated.

keon logout

Console sign-out clears the browser session and redirects to the landing page; it does not revoke API keys you minted via the CLI. Use Settings → API keys to revoke those individually.

Bearer auth from arbitrary clients

Any client that speaks HTTP can hit the control plane:

curl -H "Authorization: Bearer $KISENON_API_KEY" \
  https://api.test.kisenon.com/v1/projects

The bearer token is either an API key (nsk_…) or a cp-signed JWT issued via /v1/auth/exchange. Both are equivalent for organization-scoped endpoints.

Organizations — organizations, roles, and switching.
Invitations — add teammates to an organization.
CLI — install, login, common commands.
Security — disclosure policy.
FAQ — short answers to the most-asked questions.

On this page