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 (incluidokeon) puede presentar como credencialBearer.
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 alcance —
org,projectobranch. 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 obtienen403 scope_insufficient. - Capacidad —
readoread_write. Una clavereades 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:
- La CLI inicia un escucha HTTP local en un puerto alto aleatorio.
- 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. - Inicia sesión (o ya tiene sesión iniciada) y hace clic en Authorize.
- La consola redirige a la URL de loopback con un código de vida corta.
- La CLI intercambia el código en
POST /v1/cli/exchangepor una clave de API recién acuñada. - La clave se persiste en
~/.config/keon/credentials.jsoncon modo0600.
Tras el flujo, keon whoami confirma que la clave está conectada:
keon login
keon whoamiLa 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 logoutEl 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/projectsEl 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.
Enmascaramiento de datos
Anonimiza la PII en la creación de un branch — políticas de enmascaramiento, la biblioteca de funciones integradas y cómo los branches enmascarados permanecen sellados hasta que el enmascaramiento se confirma.
Organizaciones
Las organizaciones son la unidad de membresía y facturación — miembros, roles y cambio.