Autenticação

A Kisenon tem duas maneiras de autenticar:

Sign-in web — OAuth do Google ou 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 operar a CLI, o CI e chamadas pontuais via curl.

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 cerca de 15 minutos após a emissão. Enquanto você está ativo, o NextAuth o renova em segundo plano reapresentando o JWT atual a 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 sign-in; uma vez que essa janela expira, a próxima requisição redireciona você para o sign-in.

Acesso durante o alpha

O sign-in é restrito. Apenas e-mails na allowlist do alpha podem completar a troca — uma conta não listada recebe um 403 email_not_allowed de volta de /v1/auth/exchange e nunca recebe uma sessão. Contas na allowlist que fizeram sign-in mas ainda não foram aprovadas ficam em estado pendente: o console as redireciona para /pending, e o control plane responde chamadas de API restritas com 403 alpha_pending até que um operador aprove a conta. Veja Acesso ao alpha para se candidatar.

Organizações e papéis

A identidade é centrada na organização. 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 ganham uma organização pessoal automaticamente; usuários convidados aterrissam na organização da equipe no primeiro sign-in.

Se você pertence a mais de uma organização, o seletor de organizações no console (no topo do layout autenticado) as lista com um selo de papel. Escolher uma faz POST para /api/auth/switch-org, que faz proxy para o /v1/auth/switch-org do cp e insere um JWT novo — com escopo na 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 entender como organizações e papéis funcionam, e Convites para adicionar colegas de equipe.

Chaves de API

Chaves de API são credenciais com escopo na organização. Cada chave:

Carrega o formato nsk_<random> e é mostrada uma única vez na criação.
É armazenada com hash. Não conseguimos recuperar o texto puro após a criação, então salve-a agora ou rotacione-a depois.
Pertence a uma organização e atua com a sua identidade dentro dela.
Pode ser revogada a qualquer momento sem afetar outras chaves.

Gerencie chaves em Settings → API keys no console. Cada linha mostra o nome da chave, o id, a data de criação e quando foi usada pela última vez. Criar exige um nome e revela o segredo uma vez; revogar e renomear são inline.

Escopos e capacidade

O control plane dá escopo a cada chave de duas formas:

Tipo de escopo — org, project ou branch. Uma chave com escopo na organização alcança tudo na organização; uma chave com escopo em projeto ou branch é restrita ao(s) projeto(s) nomeado(s) ou ao branch, e requisições para qualquer outro recurso recebem 403 scope_insufficient.
Capacidade — read ou read_write. Uma chave read é recusada em qualquer chamada de mutação.

Chaves criadas pelo console hoje têm escopo na organização com capacidade read_write — ainda não há seletor de escopo na UI. Escopos mais estreitos de projeto/branch e a capacidade read estão disponíveis fazendo POST de um scope e capability diretamente ao endpoint /v1/api-keys/ do cp.

OAuth de loopback da CLI

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

A CLI inicia um listener HTTP local em uma porta alta aleatória.
Ela abre o seu navegador em https://kisenon.com/cli/authorize?... com um state token de uso único e a URL de redirecionamento de loopback.
Você faz sign-in (ou já está autenticado) e clica em Authorize.
O console redireciona para a URL de loopback com um code de vida curta.
A CLI troca o code 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 code do OAuth, o state, nem nenhum token do lado do provedor; apenas a chave de API resultante. Rotacione ou revogue essa chave pelo console a qualquer momento.

Logout

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 landing page; ele não revoga chaves de API que você cunhou via CLI. Use Settings → API keys para revogar essas 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.test.kisenon.com/v1/projects

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

Relacionado

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

Autenticação

On this page