Authentifizierung

Kisenon bietet zwei Wege zur Authentifizierung:

Web-Anmeldung — Google- oder GitHub-OAuth via NextAuth in der Konsole.
API-Schlüssel — ein nsk_…-Token, das jeder HTTP-Client (einschließlich keon) als Bearer-Anmeldeinformation vorlegen kann.

Derselbe Schlüssel kann die CLI, CI und einmalige curl-Aufrufe antreiben.

Web-Anmeldung

Öffnen Sie kisenon.com und klicken Sie auf Anmelden. Wählen Sie Google oder GitHub. NextAuth wickelt den OAuth-Ablauf ab und tauscht dann das ID-Token des Anbieters gegen ein Control-Plane-JWT via POST /v1/auth/exchange. Dieses cp-signierte JWT ist die Anmeldeinformation, die jede nachfolgende Konsolenanfrage mitführt.

Das JWT ist kurzlebig — es läuft etwa 15 Minuten nach Ausstellung ab. Während Sie aktiv sind, aktualisiert NextAuth es im Hintergrund, indem es das aktuelle JWT erneut an POST /v1/auth/refresh vorlegt, das ein frisches ausstellt. Die Aktualisierungs-Anmeldeinformation ist das JWT selbst, gültig innerhalb eines 12-Stunden-Fensters ab Anmeldung; sobald dieses Fenster abläuft, leitet die nächste Anfrage Sie zur Anmeldung um.

Zugang

Melden Sie sich mit Google oder GitHub an. Wenn die offene Registrierung aktiviert ist, ist ein neues Konto sofort nutzbar: Der erste Austausch legt Ihren Benutzer und eine persönliche Organisation an, und Sie landen direkt in der Konsole.

Der Zugang kann eingeschränkt werden, während wir neue Konten onboarden — ein Kill-Switch, den der Operator pro Umgebung umlegen kann. Ist er aktiv, landet ein Konto, das sich angemeldet hat, aber noch nicht freigeschaltet ist, in einem pending-Zustand: Die Konsole leitet es zu /pending um, und die Control Plane beantwortet gesperrte API-Aufrufe mit 403 alpha_pending, bis das Konto freigeschaltet ist. Eine konfigurierte Anmelde-Zulassungsliste kann ein nicht gelistetes Konto zudem mit 403 email_not_allowed ablehnen, bevor überhaupt eine Session ausgestellt wird.

Organisationen und Rollen

Identität ist organisationsorientiert. Jede Session führt eine aktive Organisation und Ihre Rolle darin mit (zum Beispiel owner oder member); das cp-JWT codiert beides, und die Control Plane liest Ihre Rolle bei jeder Aktualisierung neu ein. Persönliche Anmeldungen erhalten automatisch eine persönliche Organisation; eingeladene Benutzer landen bei der ersten Anmeldung in der Team-Organisation.

Wenn Sie mehr als einer Organisation angehören, listet der Organisations-Umschalter in der Konsole (oben im angemeldeten Layout) sie mit einem Rollen-Badge auf. Die Auswahl einer Organisation sendet ein POST an /api/auth/switch-org, das an cps /v1/auth/switch-org weiterleitet und ein frisches JWT — beschränkt auf die neue Organisation — in Ihre Session einfügt. Alle Konsolenanfragen nach dem Wechsel handeln in der ausgewählten Organisation.

Siehe Organisationen dazu, wie Organisationen und Rollen funktionieren, und Einladungen zum Hinzufügen von Teamkollegen.

API-Schlüssel

API-Schlüssel sind Anmeldeinformationen mit nsk_-Präfix. Jeder Schlüssel:

Trägt das Format nsk_<random> und wird bei der Erstellung einmal angezeigt — er wird at-rest gehasht, sodass wir den Klartext später nicht wiederherstellen können. Speichern Sie ihn jetzt oder rotieren Sie ihn.
Handelt mit Ihrer Identität innerhalb seines Scopes.
Kann jederzeit widerrufen werden, ohne andere Schlüssel zu beeinträchtigen.

Einen Schlüssel über die Konsole erstellen

Erstellen Sie Schlüssel unter Einstellungen → API-Schlüssel. Jede Zeile zeigt den Namen des Schlüssels, die ID, das Erstellungsdatum und wann er zuletzt verwendet wurde. Das Erstellungsformular hat vier Felder:

Name — eine Bezeichnung, bis zu 64 Zeichen.
Capability — siehe unten.
Scope — siehe unten.
Läuft ab (Tage) — leer lassen für einen Schlüssel, der nie abläuft.

Absenden, und das Geheimnis wird einmal enthüllt. Kopieren Sie es, bevor Sie den Dialog schließen.

Capability wählt aus, was der Schlüssel tun darf:

read_write (Standard) — vollständiges Lesen und Schreiben.
read — nur-lesend; bei jedem mutierenden Aufruf abgelehnt.
agent — kann Sandboxes antreiben, kann aber keine schreibfähige main- Anmeldeinformation abrufen. Übergeben Sie diese Capability an KI-Agenten, damit sie gegen Branches arbeiten, ohne jemals das produktive main zu berühren. Siehe Agent-Safe Change Control.

Scope wählt aus, was der Schlüssel erreichen kann:

Organisation (Standard) — alles in der aktiven Organisation.
Ein bestimmtes Projekt — auf dieses Projekt beschränkt; Anfragen für jede andere Ressource erhalten 403 scope_insufficient. (Branch-Scope wird ebenfalls über die API unterstützt.)

Das Erstellen eines Schlüssels erfordert eine angemeldete Browser-Session — ein nsk_-Schlüssel kann keinen anderen Schlüssel erstellen. Ein Schlüssel kann sich selbst widerrufen, aber ein nsk_- Bearer kann sich nur selbst widerrufen; er kann keine anderen Schlüssel löschen.

Über die API

Dieselben Operationen sind an cps /v1/api-keys/-Endpoint verfügbar: POSTen Sie einen name, scope und eine capability zum Erstellen, und die Antwort trägt das Klartext-Geheimnis einmal.

IP-Zulassungsliste

Jedes Projekt kann eine Netzwerk-Zulassungsliste von CIDRs tragen. Wenn die Liste gesetzt ist, erreichen nur Verbindungen, die von einem gelisteten CIDR stammen, die Endpoints des Projekts; die Durchsetzung deckt den Wake-Pfad ab, sodass ein nicht gelisteter Client auch keinen suspendierten Endpoint aufwecken kann. Eine leere Zulassungsliste bedeutet keine IP- Beschränkung — alle Quellen sind erlaubt.

Verwalten Sie die Liste über die 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...

Oder über die API:

GET /v1/projects/{projectId}/ip-allow — die aktuellen Regeln auflisten.
POST /v1/projects/{projectId}/ip-allow — eine Regel hinzufügen. Der Body ist {cidr, label, ttl_seconds?}; ttl_seconds ist optional und macht die Regel selbstablaufend. Ein fehlerhaftes CIDR gibt 422 zurück.
DELETE /v1/projects/{projectId}/ip-allow/{cidr} — eine Regel entfernen.
DELETE /v1/projects/{projectId}/ip-allow — die gesamte Liste zurücksetzen.

Die Durchsetzung erfolgt am Proxy, der seine Ansicht etwa alle 30 Sekunden aktualisiert, sodass sich eine Änderung innerhalb von Sekunden verbreitet.

CLI-Loopback-OAuth

keon login bittet Sie nicht, einen API-Schlüssel einzufügen. Stattdessen führt es einen Loopback-OAuth-Flow aus:

Die CLI startet einen lokalen HTTP-Listener auf einem zufälligen hohen Port.
Sie öffnet Ihren Browser zu https://kisenon.com/cli/authorize?... mit einem Einmal-State-Token und der Loopback-Redirect-URL.
Sie melden sich an (oder sind bereits angemeldet) und klicken auf Autorisieren.
Die Konsole leitet zur Loopback-URL mit einem kurzlebigen Code um.
Die CLI tauscht den Code bei POST /v1/cli/exchange gegen einen frisch erzeugten API-Schlüssel.
Der Schlüssel wird unter ~/.config/keon/credentials.json mit Modus 0600 persistiert.

Nach dem Flow bestätigt keon whoami, dass der Schlüssel verdrahtet ist:

keon login
keon whoami

Die CLI speichert weder den OAuth-Code, den State noch ein provider-seitiges Token; nur den resultierenden API-Schlüssel. Rotieren oder widerrufen Sie diesen Schlüssel jederzeit über die Konsole.

Logout

keon logout widerruft den lokalen API-Schlüssel auf dem Server und entfernt die Anmeldeinformationsdatei. Nach dem Logout erzeugt derselbe keon login-Flow einen neuen Schlüssel — alte Anmeldeinformationen können nicht reaktiviert werden.

keon logout

Die Konsolenabmeldung löscht die Browser-Session und leitet zur Landingpage um; sie widerruft keine API-Schlüssel, die Sie über die CLI erzeugt haben. Verwenden Sie Einstellungen → API-Schlüssel, um diese einzeln zu widerrufen.

Bearer-Auth von beliebigen Clients

Jeder Client, der HTTP spricht, kann die Control Plane erreichen:

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

Das Bearer-Token ist entweder ein API-Schlüssel (nsk_…) oder ein cp-signiertes JWT, ausgestellt via /v1/auth/exchange. Beide sind für organisationsbezogene Endpoints gleichwertig.