kisenon

Autenticación

Inicio de sesión, organizaciones, claves de API y el flujo OAuth de loopback de la CLI.

Kisenon tiene dos formas de autenticarse:

  • Inicio de sesión web — OAuth de Google o GitHub mediante NextAuth en la consola.
  • Clave de API — un token nsk_… que cualquier cliente HTTP (incluido keon) puede presentar como credencial Bearer.

La misma clave puede impulsar la CLI, CI y llamadas puntuales con curl.

Inicio de sesión web

Abra kisenon.com y haga clic en Sign in. Elija Google o GitHub. NextAuth gestiona el baile de OAuth y luego intercambia el id token del proveedor por un JWT del plano de control mediante POST /v1/auth/exchange. Ese JWT firmado por cp es la credencial que lleva cada solicitud posterior de la consola.

El JWT es de vida corta — expira aproximadamente 15 minutos después de su emisión. Mientras está activo, NextAuth lo renueva en segundo plano volviendo a presentar el JWT actual a POST /v1/auth/refresh, que acuña uno nuevo. La credencial de renovación es el propio JWT, válido dentro de una ventana de 12 horas desde el inicio de sesión; una vez que esa ventana caduca, la siguiente solicitud le redirige al inicio de sesión.

Acceso durante la alpha

El inicio de sesión está restringido. Solo los correos en la lista de permitidos de la alpha pueden completar el intercambio — una cuenta no listada recibe un 403 email_not_allowed de /v1/auth/exchange y nunca recibe una sesión. Las cuentas en la lista de permitidos que han iniciado sesión pero aún no están aprobadas quedan en un estado pendiente: la consola las redirige a /pending, y el plano de control responde las llamadas de API restringidas con 403 alpha_pending hasta que un operador aprueba la cuenta. Consulte Acceso alpha para solicitarlo.

Organizaciones y roles

La identidad es primero la organización. Cada sesión lleva una organización activa y su rol en ella (por ejemplo owner o member); el JWT de cp codifica ambos, y el plano de control vuelve a leer su rol en cada renovación. Los registros personales obtienen una organización personal automáticamente; los usuarios invitados aterrizan en la organización del equipo en su primer inicio de sesión.

Si pertenece a más de una organización, el selector de organizaciones en la consola (parte superior del diseño con sesión iniciada) las lista con una insignia de rol. Elegir una hace un POST a /api/auth/switch-org, que actúa como proxy hacia el /v1/auth/switch-org de cp y empalma un JWT nuevo — limitado a la nueva organización — en su sesión. Todas las solicitudes de la consola tras el cambio actúan en la organización seleccionada.

Consulte Organizaciones para saber cómo funcionan las organizaciones y los roles, e Invitaciones para añadir compañeros de equipo.

Claves de API

Las claves de API son credenciales limitadas a la organización. Cada clave:

  • Lleva el formato nsk_<random> y se muestra una sola vez en su creación.
  • Se almacena con hash. No podemos recuperar el texto plano tras la creación, así que guárdela ahora o rótela más tarde.
  • Pertenece a una organización y actúa con su identidad dentro de ella.
  • Puede revocarse en cualquier momento sin afectar a otras claves.

Gestione las claves en Settings → API keys en la consola. Cada fila muestra el nombre de la clave, su id, la fecha de creación y cuándo se usó por última vez. Crear toma un nombre y revela el secreto una vez; revocar y renombrar son acciones en línea.

Alcances y capacidad

El plano de control limita cada clave de dos maneras:

  • Tipo de alcanceorg, project o branch. Una clave limitada a la organización alcanza todo en la organización; una clave limitada a un proyecto o rama está restringida al proyecto o rama nombrados, y las solicitudes para cualquier otro recurso obtienen 403 scope_insufficient.
  • Capacidadread o read_write. Una clave read es rechazada en cualquier llamada que mute.

Las claves creadas desde la consola hoy están limitadas a la organización con capacidad read_write — todavía no hay un selector de alcance en la interfaz. Los alcances más estrechos de proyecto/rama y la capacidad read están disponibles haciendo POST de un scope y una capability directamente al endpoint /v1/api-keys/ de cp.

OAuth de loopback de la CLI

keon login no le pide pegar una clave de API. En su lugar ejecuta un flujo OAuth de loopback:

  1. La CLI inicia un escucha HTTP local en un puerto alto aleatorio.
  2. Abre su navegador en https://kisenon.com/cli/authorize?... con un token de estado de un solo uso y la URL de redirección de loopback.
  3. Inicia sesión (o ya tiene sesión iniciada) y hace clic en Authorize.
  4. La consola redirige a la URL de loopback con un código de vida corta.
  5. La CLI intercambia el código en POST /v1/cli/exchange por una clave de API recién acuñada.
  6. La clave se persiste en ~/.config/keon/credentials.json con modo 0600.

Tras el flujo, keon whoami confirma que la clave está conectada:

keon login
keon whoami

La CLI no almacena el código OAuth, el estado ni ningún token del lado del proveedor; solo la clave de API resultante. Rote o revoque esa clave desde la consola en cualquier momento.

Cierre de sesión

keon logout revoca la clave de API local en el servidor y elimina el archivo de credenciales. Tras el cierre de sesión, el mismo flujo de keon login acuña una clave nueva — las credenciales antiguas no pueden reactivarse.

keon logout

El cierre de sesión de la consola borra la sesión del navegador y redirige a la página de inicio; no revoca las claves de API que haya acuñado mediante la CLI. Use Settings → API keys para revocarlas individualmente.

Autenticación Bearer desde clientes arbitrarios

Cualquier cliente que hable HTTP puede llegar al plano de control:

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

El token bearer es o bien una clave de API (nsk_…) o un JWT firmado por cp emitido mediante /v1/auth/exchange. Ambos son equivalentes para los endpoints limitados a la organización.

Relacionado

  • Organizaciones — organizaciones, roles y cambio.
  • Invitaciones — añadir compañeros de equipo a una organización.
  • CLI — instalar, iniciar sesión, comandos comunes.
  • Seguridad — política de divulgación.
  • Preguntas frecuentes — respuestas breves a las preguntas más habituales.