Autenticação

O Kisenon tem duas formas de autenticação:

Login na web — OAuth do Google ou do GitHub via NextAuth no console.
Chave de API — um token nsk_… que qualquer cliente HTTP (incluindo o keon) pode apresentar como credencial Bearer.

A mesma chave pode conduzir a CLI, o CI e chamadas curl avulsas.

Abra kisenon.com e clique em Sign in. Escolha Google ou GitHub. O NextAuth conduz a dança do OAuth e, em seguida, troca o id token do provedor por um JWT do control plane via POST /v1/auth/exchange. Esse JWT assinado pelo cp é a credencial que toda requisição subsequente do console carrega.

O JWT tem vida curta — ele expira aproximadamente 15 minutos após a emissão. Enquanto você está ativo, o NextAuth o renova em segundo plano reapresentando o JWT atual ao POST /v1/auth/refresh, que cunha um novo. A credencial de renovação é o próprio JWT, válido dentro de uma janela de 12 horas a partir do login; uma vez que essa janela expira, a próxima requisição redireciona você para o login.

Acesso

Faça login com Google ou GitHub. Quando o cadastro aberto está habilitado, uma nova conta é utilizável imediatamente: a primeira troca cria o seu usuário e uma organização pessoal, e você chega direto ao console.

O acesso pode ser limitado enquanto fazemos o onboarding — um kill-switch que o operador pode acionar por ambiente. Quando está ligado, uma conta que fez login mas ainda não foi habilitada chega a um estado pending: o console a redireciona para /pending, e o control plane responde às chamadas de API restritas com 403 alpha_pending até que a conta seja habilitada. Uma allowlist de login configurada também pode rejeitar uma conta não listada com 403 email_not_allowed antes que qualquer sessão seja emitida.

Organizações e papéis

A identidade é organização-primeiro. Cada sessão carrega uma organização ativa e o seu papel nela (por exemplo owner ou member); o JWT do cp codifica ambos, e o control plane relê o seu papel a cada renovação. Cadastros pessoais recebem uma organização pessoal automaticamente; usuários convidados chegam à organização da equipe no primeiro login.

Se você pertence a mais de uma organização, o seletor de organização no console (topo do layout com login) as lista com um selo de papel. Escolher uma faz um POST para /api/auth/switch-org, que faz proxy para o /v1/auth/switch-org do cp e insere um JWT novo — escopado à nova organização — na sua sessão. Todas as requisições do console após a troca atuam na organização selecionada.

Veja Organizações para saber como organizações e papéis funcionam, e Convites para adicionar colegas de equipe.

Chaves de API

As chaves de API são credenciais com prefixo nsk_. Cada chave:

Carrega o formato nsk_<random> e é exibida uma única vez na criação — ela é hasheada em repouso, então não podemos recuperar o texto puro depois. Salve-a agora ou faça a rotação.
Atua com a sua identidade dentro do seu escopo.
Pode ser revogada a qualquer momento sem afetar outras chaves.

Cunhando uma chave a partir do console

Cunhe chaves em Settings → API keys. Cada linha mostra o nome da chave, o id, a data de criação e quando ela foi usada pela última vez. O formulário de criação tem quatro campos:

Name — um rótulo, de até 64 caracteres.
Capability — veja abaixo.
Scope — veja abaixo.
Expires (days) — deixe em branco para uma chave que nunca expira.

Envie, e o segredo é revelado uma única vez. Copie-o antes de fechar o diálogo.

Capability escolhe o que a chave pode fazer:

read_write (padrão) — leitura e escrita completas.
read — somente leitura; recusada em qualquer chamada que modifica.
agent — pode conduzir sandboxes mas não pode obter uma credencial gravável para o main. Entregue essa capability a agentes de IA para que operem contra branches sem nunca tocar o main de produção. Veja Controle de Mudanças Seguro para Agentes.

Scope escolhe o que a chave pode alcançar:

Organization (padrão) — tudo na organização ativa.
Um projeto específico — restrito a esse projeto; requisições para qualquer outro recurso recebem 403 scope_insufficient. (O escopo de branch também é suportado via API.)

Criar uma chave requer uma sessão de navegador com login — uma chave nsk_ não pode cunhar outra chave. Uma chave pode revogar a si mesma, mas um portador nsk_ só pode auto-revogar; ele não pode excluir outras chaves.

Via a API

As mesmas operações estão disponíveis no endpoint /v1/api-keys/ do cp: faça POST de um name, scope e capability para criar, e a resposta carrega o segredo em texto puro uma única vez.

Allowlist de IP

Cada projeto pode carregar uma allowlist de rede de CIDRs. Quando a lista está definida, apenas conexões originadas de um CIDR listado alcançam os endpoints do projeto; a aplicação cobre o caminho de wake, então um cliente não listado não pode acordar um endpoint suspenso tampouco. Uma allowlist vazia significa nenhuma restrição de IP — todas as origens são permitidas.

Gerencie a lista a partir da CLI:

keon ip-allow add 203.0.113.0/24 --project prj_abc...
keon ip-allow list --project prj_abc...
keon ip-allow remove 203.0.113.0/24 --project prj_abc...

Ou pela API:

GET /v1/projects/{projectId}/ip-allow — lista as regras atuais.
POST /v1/projects/{projectId}/ip-allow — adiciona uma regra. O corpo é {cidr, label, ttl_seconds?}; ttl_seconds é opcional e torna a regra autoexpirável. Um CIDR malformado retorna 422.
DELETE /v1/projects/{projectId}/ip-allow/{cidr} — remove uma regra.
DELETE /v1/projects/{projectId}/ip-allow — redefine a lista inteira.

A aplicação é no proxy, que atualiza sua visão a cada cerca de 30 segundos, então uma mudança se propaga em segundos.

OAuth por loopback da CLI

O keon login não pede que você cole uma chave de API. Em vez disso, ele executa um fluxo de OAuth por loopback:

A CLI inicia um listener HTTP local em uma porta alta aleatória.
Ela abre seu navegador em https://kisenon.com/cli/authorize?... com um token de estado de uso único e a URL de redirecionamento de loopback.
Você faz login (ou já está logado) e clica em Authorize.
O console redireciona para a URL de loopback com um código de vida curta.
A CLI troca o código em POST /v1/cli/exchange por uma chave de API recém-cunhada.
A chave é persistida em ~/.config/keon/credentials.json com modo 0600.

Após o fluxo, keon whoami confirma que a chave está conectada:

keon login
keon whoami

A CLI não armazena o código de OAuth, o estado, nem nenhum token do lado do provedor; apenas a chave de API resultante. Faça a rotação ou revogue essa chave pelo console a qualquer momento.

Logout

O keon logout revoga a chave de API local no servidor e remove o arquivo de credenciais. Após o logout, o mesmo fluxo keon login cunha uma nova chave — credenciais antigas não podem ser reativadas.

keon logout

O sign-out do console limpa a sessão do navegador e redireciona para a página inicial; ele não revoga as chaves de API que você cunhou via CLI. Use Settings → API keys para revogá-las individualmente.

Autenticação Bearer a partir de clientes arbitrários

Qualquer cliente que fale HTTP pode acessar o control plane:

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

O token bearer é uma chave de API (nsk_…) ou um JWT assinado pelo cp emitido via /v1/auth/exchange. Ambos são equivalentes para endpoints escopados por organização.

Relacionados

Organizações — organizações, papéis e troca.
Convites — adicione colegas de equipe a uma organização.
CLI — instalação, login, comandos comuns.
Segurança — política de divulgação.
FAQ — respostas curtas às perguntas mais frequentes.

Autenticação

On this page