Authentification

Kisenon propose deux moyens de s'authentifier :

Connexion web — OAuth Google ou GitHub via NextAuth sur la console.
Clé API — un jeton nsk_… que n'importe quel client HTTP (y compris keon) peut présenter comme identifiant Bearer.

La même clé peut piloter la CLI, la CI et des appels curl ponctuels.

Connexion web

Ouvrez kisenon.com et cliquez sur Sign in. Choisissez Google ou GitHub. NextAuth gère la chorégraphie OAuth, puis échange le jeton d'identité du fournisseur contre un JWT du plan de contrôle via POST /v1/auth/exchange. Ce JWT signé par cp est l'identifiant que porte chaque requête console ultérieure.

Le JWT a une courte durée de vie — il expire environ 15 minutes après son émission. Tant que vous êtes actif, NextAuth le renouvelle en arrière-plan en re-présentant le JWT courant à POST /v1/auth/refresh, qui en émet un nouveau. L'identifiant de renouvellement est le JWT lui-même, valide dans une fenêtre de 12 heures à compter de la connexion ; une fois cette fenêtre écoulée, la requête suivante vous redirige vers la page de connexion.

Accès

Connectez-vous avec Google ou GitHub. Lorsque l'inscription ouverte est activée, un nouveau compte est immédiatement utilisable : le premier échange crée votre utilisateur et une organisation personnelle, et vous arrivez directement dans la console.

L'accès peut être limité pendant que nous vous intégrons — un coupe-circuit que l'opérateur peut actionner par environnement. Lorsqu'il est activé, un compte qui s'est connecté mais n'est pas encore activé arrive dans un état en attente : la console le redirige vers /pending, et le plan de contrôle répond aux appels API restreints par 403 alpha_pending jusqu'à ce que le compte soit activé. Une liste d'autorisation de connexion configurée peut aussi rejeter un compte non listé avec 403 email_not_allowed avant qu'une session ne soit émise.

Organisations et rôles

L'identité est axée sur l'organisation. Chaque session porte une organisation active et votre rôle au sein de celle-ci (par exemple owner ou member) ; le JWT cp encode les deux, et le plan de contrôle relit votre rôle à chaque renouvellement. Les inscriptions personnelles obtiennent automatiquement une organisation personnelle ; les utilisateurs invités arrivent dans l'organisation d'équipe à la première connexion.

Si vous appartenez à plusieurs organisations, le sélecteur d'organisation de la console (en haut de la mise en page connectée) les liste avec un badge de rôle. En choisir une envoie un POST à /api/auth/switch-org, qui relaie vers le /v1/auth/switch-org de cp et insère un JWT frais — restreint à la nouvelle organisation — dans votre session. Toutes les requêtes console après le changement agissent dans l'organisation sélectionnée.

Voir Organisations pour le fonctionnement des organisations et des rôles, et Invitations pour ajouter des coéquipiers.

Clés API

Les clés API sont des identifiants préfixés par nsk_. Chaque clé :

Porte le format nsk_<random> et n'est affichée qu'une seule fois à la création — elle est hachée au repos, nous ne pouvons donc pas récupérer le texte en clair par la suite. Enregistrez-la maintenant ou faites-la tourner.
Agit avec votre identité dans sa portée.
Peut être révoquée à tout moment sans affecter les autres clés.

Créer une clé depuis la console

Créez des clés dans Settings → API keys. Chaque ligne affiche le nom de la clé, son id, la date de création et sa dernière utilisation. Le formulaire de création comporte quatre champs :

Name — un libellé, jusqu'à 64 caractères.
Capability — voir ci-dessous.
Scope — voir ci-dessous.
Expires (days) — laissez vide pour une clé qui n'expire jamais.

Soumettez, et le secret est révélé une seule fois. Copiez-le avant de fermer la boîte de dialogue.

Capability choisit ce que la clé peut faire :

read_write (par défaut) — lecture et écriture complètes.
read — lecture seule ; refusée sur tout appel mutateur.
agent — peut piloter des sandboxes mais ne peut pas obtenir un identifiant autorisé en écriture sur main. Confiez cette capacité aux agents IA afin qu'ils opèrent sur des branches sans jamais toucher le main de production. Voir Agent-Safe Change Control.

Scope choisit ce que la clé peut atteindre :

Organization (par défaut) — tout dans l'organisation active.
Un projet spécifique — restreint à ce projet ; les requêtes vers toute autre ressource obtiennent 403 scope_insufficient. (La portée par branche est aussi prise en charge via l'API.)

Créer une clé nécessite une session de navigateur connectée — une clé nsk_ ne peut pas créer une autre clé. Une clé peut se révoquer elle-même, mais un porteur nsk_ ne peut qu'auto-révoquer ; il ne peut pas supprimer d'autres clés.

Via l'API

Les mêmes opérations sont disponibles sur l'endpoint /v1/api-keys/ de cp : POST un name, un scope et une capability pour créer, et la réponse porte le secret en clair une seule fois.

Liste d'autorisation d'IP

Chaque projet peut porter une liste d'autorisation réseau de CIDR. Lorsque la liste est définie, seules les connexions provenant d'un CIDR listé atteignent les endpoints du projet ; l'application couvre le chemin de réveil, de sorte qu'un client non listé ne peut pas réveiller un endpoint suspendu non plus. Une liste d'autorisation vide signifie aucune restriction d'IP — toutes les sources sont autorisées.

Gérez la liste depuis 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...

Ou via l'API :

GET /v1/projects/{projectId}/ip-allow — liste les règles courantes.
POST /v1/projects/{projectId}/ip-allow — ajoute une règle. Le corps est {cidr, label, ttl_seconds?} ; ttl_seconds est facultatif et rend la règle auto-expirante. Un CIDR mal formé renvoie 422.
DELETE /v1/projects/{projectId}/ip-allow/{cidr} — supprime une règle.
DELETE /v1/projects/{projectId}/ip-allow — réinitialise toute la liste.

L'application se fait au niveau du proxy, qui rafraîchit sa vue environ toutes les 30 secondes, de sorte qu'un changement se propage en quelques secondes.

OAuth en boucle locale de la CLI

keon login ne vous demande pas de coller une clé API. À la place, il exécute un flux OAuth en boucle locale :

La CLI démarre un écouteur HTTP local sur un port élevé aléatoire.
Elle ouvre votre navigateur sur https://kisenon.com/cli/authorize?... avec un jeton d'état à usage unique et l'URL de redirection en boucle locale.
Vous vous connectez (ou êtes déjà connecté) et cliquez sur Authorize.
La console redirige vers l'URL de boucle locale avec un code à courte durée de vie.
La CLI échange le code à POST /v1/cli/exchange contre une clé API fraîchement créée.
La clé est persistée dans ~/.config/keon/credentials.json avec le mode 0600.

Après le flux, keon whoami confirme que la clé est bien câblée :

keon login
keon whoami

La CLI ne stocke pas le code OAuth, l'état, ni aucun jeton côté fournisseur ; seulement la clé API résultante. Faites tourner ou révoquez cette clé depuis la console à tout moment.

Déconnexion

keon logout révoque la clé API locale sur le serveur et supprime le fichier d'identifiants. Après la déconnexion, le même flux keon login crée une nouvelle clé — les anciens identifiants ne peuvent pas être réactivés.

keon logout

La déconnexion de la console efface la session de navigateur et redirige vers la page d'accueil ; elle ne révoque pas les clés API que vous avez créées via la CLI. Utilisez Settings → API keys pour révoquer celles-ci individuellement.

Auth Bearer depuis des clients arbitraires

Tout client qui parle HTTP peut interroger le plan de contrôle :

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

Le jeton bearer est soit une clé API (nsk_…), soit un JWT signé par cp émis via /v1/auth/exchange. Les deux sont équivalents pour les endpoints à portée d'organisation.

Voir aussi

Organisations — organisations, rôles et changement.
Invitations — ajouter des coéquipiers à une organisation.
CLI — installation, connexion, commandes courantes.
Sécurité — politique de divulgation.
FAQ — réponses brèves aux questions les plus fréquentes.

Authentification

On this page