Autenticación

Kisenon tiene dos formas de autenticarse:

• Inicio de sesión web — OAuth de Google o GitHub a través de 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 de curl.

Inicio de sesión web

Abre kisenon.com y haz clic en Sign in. Elige Google o GitHub. NextAuth gestiona el intercambio de OAuth y luego canjea el token de identidad 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 corta duración — expira aproximadamente 15 minutos después de emitirse. Mientras estás 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 te redirige al inicio de sesión.

Acceso

Inicia sesión con Google o GitHub. Cuando el registro abierto está habilitado, una nueva cuenta es utilizable de inmediato: el primer intercambio crea tu usuario y una organización personal, y aterrizas directamente en la consola.

El acceso puede limitarse mientras hacemos el onboarding — un interruptor de corte que el operador puede activar por entorno. Cuando está activado, una cuenta que ha iniciado sesión pero aún no está habilitada aterriza en un estado pendiente: la consola la redirige a /pending, y el plano de control responde a las llamadas de API restringidas con 403 alpha_pending hasta que la cuenta se habilita. Una lista de permitidos de inicio de sesión configurada también puede rechazar una cuenta no incluida con 403 email_not_allowed antes de que se emita ninguna sesión.

Organizaciones y roles

La identidad es organización-primero. Cada sesión lleva una organización activa y tu rol en ella (por ejemplo owner o member); el JWT de cp codifica ambos, y el plano de control vuelve a leer tu 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 el primer inicio de sesión.

Si perteneces a más de una organización, el selector de organizaciones de 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 hace de proxy hacia el /v1/auth/switch-org de cp e inserta un JWT nuevo — con alcance a la nueva organización — en tu sesión. Todas las solicitudes de la consola tras el cambio actúan en la organización seleccionada.

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

Claves de API

Las claves de API son credenciales con prefijo nsk_. Cada clave:

• Lleva el formato nsk_<random> y se muestra una sola vez en su creación — se almacena con hash, por lo que no podemos recuperar el texto plano más tarde. Guárdala ahora o rótala.
• Actúa con tu identidad dentro de su alcance.
• Puede revocarse en cualquier momento sin afectar a otras claves.

Acuñar una clave desde la consola

Acuña claves en Settings → API keys. Cada fila muestra el nombre de la clave, su id, la fecha de creación y cuándo se usó por última vez. El formulario de creación tiene cuatro campos:

• Name — una etiqueta, de hasta 64 caracteres.
• Capability — véase más abajo.
• Scope — véase más abajo.
• Expires (days) — déjalo en blanco para una clave que nunca expira.

Envía, y el secreto se revela una sola vez. Cópialo antes de cerrar el diálogo.

Capability elige lo que la clave puede hacer:

• read_write (predeterminado) — lectura y escritura completas.
• read — solo lectura; rechazada en cualquier llamada que mute.
• agent — puede impulsar sandboxes pero no puede obtener una credencial de main con permiso de escritura. Entrega esta capacidad a los agentes de IA para que operen contra ramas sin tocar nunca el main de producción. Consulta Control de Cambios Seguro para Agentes.

Scope elige lo que la clave puede alcanzar:

• Organization (predeterminado) — todo en la organización activa.
• Un proyecto específico — restringido a ese proyecto; las solicitudes de cualquier otro recurso reciben 403 scope_insufficient. (El alcance de rama también se admite mediante la API.)

Crear una clave requiere una sesión de navegador con sesión iniciada — una clave nsk_ no puede acuñar otra clave. Una clave puede revocarse a sí misma, pero un portador nsk_ solo puede autorevocarse; no puede eliminar otras claves.

A través de la API

Las mismas operaciones están disponibles en el endpoint /v1/api-keys/ de cp: haz un POST de un name, scope y capability para crear, y la respuesta lleva el secreto en texto plano una sola vez.

Lista de permitidos de IP

Cada proyecto puede llevar una lista de permitidos de red de CIDRs. Cuando la lista está establecida, solo las conexiones que se originan desde un CIDR listado alcanzan los endpoints del proyecto; la aplicación cubre la ruta de activación, de modo que un cliente no listado no puede activar un endpoint suspendido tampoco. Una lista de permitidos vacía significa que no hay restricción de IP — se permiten todas las fuentes.

Gestiona la lista desde la 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...

O a través de la API:

• GET /v1/projects/{projectId}/ip-allow — lista las reglas actuales.
• POST /v1/projects/{projectId}/ip-allow — añade una regla. El cuerpo es {cidr, label, ttl_seconds?}; ttl_seconds es opcional y hace que la regla expire por sí sola. Un CIDR malformado devuelve 422.
• DELETE /v1/projects/{projectId}/ip-allow/{cidr} — elimina una regla.
• DELETE /v1/projects/{projectId}/ip-allow — restablece la lista completa.

La aplicación está en el proxy, que refresca su vista cada unos 30 segundos, así que un cambio se propaga en cuestión de segundos.

OAuth loopback de la CLI

keon login no te pide que pegues una clave de API. En su lugar ejecuta un flujo de OAuth loopback:

1. La CLI inicia un listener HTTP local en un puerto alto aleatorio.
2. Abre tu navegador a https://kisenon.com/cli/authorize?... con un token de estado de un solo uso y la URL de redirección loopback.
3. Inicias sesión (o ya has iniciado sesión) y haces clic en Authorize.
4. La consola redirige a la URL loopback con un código de corta duración.
5. La CLI canjea 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. Rota o revoca 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 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 aterrizaje; no revoca las claves de API que acuñaste mediante la CLI. Usa 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.kisenon.com/v1/projects

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

Relacionado

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