Authentification

Kisenon propose deux façons 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 l'id token 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 est de courte durée — il expire environ 15 minutes après son émission. Pendant que vous êtes actif, NextAuth le rafraîchit en arrière-plan en re-présentant le JWT courant à POST /v1/auth/refresh, qui en frappe un nouveau. L'identifiant de rafraîchissement 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 connexion.

Accès pendant l'alpha

La connexion est filtrée. Seuls les e-mails sur la liste d'autorisation alpha peuvent compléter l'échange — un compte non listé reçoit un 403 email_not_allowed de /v1/auth/exchange et n'obtient jamais de session. Les comptes autorisés qui se sont connectés mais ne sont pas encore approuvés se retrouvent dans un état en attente : la console les redirige vers /pending, et le plan de contrôle répond aux appels d'API filtrés par un 403 alpha_pending jusqu'à ce qu'un opérateur approuve le compte. Voir Accès alpha pour postuler.

Organisations et rôles

L'identité est centré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 rafraîchissement. Les inscriptions personnelles obtiennent automatiquement une organisation personnelle ; les utilisateurs invités se retrouvent dans l'organisation de l'équipe lors de leur première connexion.

Si vous appartenez à plus d'une organisation, 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 POST sur /api/auth/switch-org, qui relaie vers le /v1/auth/switch-org de cp et insère un JWT frais — limité à la nouvelle organisation — dans votre session. Toutes les requêtes console après le basculement 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 limités à une organisation. Chaque clé :

• Porte le format nsk_<random> et est affichée une seule fois à la création.
• Est hachée au repos. Nous ne pouvons pas récupérer le texte en clair après la création, alors enregistrez-la maintenant ou faites-la tourner plus tard.
• Appartient à une organisation et agit avec votre identité au sein de celle-ci.
• Peut être révoquée à tout moment sans affecter les autres clés.

Gérez les clés dans Settings → API keys de la console. Chaque ligne affiche le nom de la clé, son id, la date de création et la date de dernière utilisation. La création prend un nom et révèle le secret une seule fois ; la révocation et le renommage se font en ligne.

Portées et capacité

Le plan de contrôle limite chaque clé de deux manières :

• Type de portée — org, project ou branch. Une clé limitée à une organisation atteint tout dans l'organisation ; une clé limitée à un projet ou à une branche est restreinte au(x) projet(s) ou à la branche nommés, et les requêtes vers toute autre ressource obtiennent un 403 scope_insufficient.
• Capacité — read ou read_write. Une clé read est refusée sur tout appel mutant.

Les clés créées depuis la console aujourd'hui sont limitées à une organisation avec la capacité read_write — il n'y a pas encore de sélecteur de portée dans l'interface. Des portées projet/branche plus étroites et la capacité read sont disponibles en envoyant en POST un scope et une capability directement sur l'endpoint /v1/api-keys/ de cp.

OAuth en loopback de la CLI

keon login ne vous demande pas de coller une clé API. Il exécute plutôt un flux OAuth en loopback :

1. La CLI démarre un écouteur HTTP local sur un port haut aléatoire.
2. Elle ouvre votre navigateur sur https://kisenon.com/cli/authorize?... avec un jeton d'état à usage unique et l'URL de redirection loopback.
3. Vous vous connectez (ou êtes déjà connecté) et cliquez sur Authorize.
4. La console redirige vers l'URL loopback avec un code de courte durée.
5. La CLI échange le code sur POST /v1/cli/exchange contre une clé API fraîchement frappée.
6. 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 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 obtenue. 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 frappe une nouvelle clé — les anciens identifiants ne peuvent pas être réactivés.

keon logout

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

Auth Bearer depuis des clients arbitraires

Tout client parlant HTTP peut atteindre le plan de contrôle :

curl -H "Authorization: Bearer $KISENON_API_KEY" \
  https://api.test.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 limités à une organisation.

Liens connexes

• Organisations — organisations, rôles et basculement.
• Invitations — ajouter des coéquipiers à une organisation.
• CLI — installation, login, commandes courantes.
• Sécurité — politique de divulgation.
• FAQ — réponses courtes aux questions les plus posées.