Auth

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 Sign in. Wählen Sie Google oder GitHub. NextAuth wickelt den OAuth-Tanz ab und tauscht dann das ID-Token des Providers 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 während der Alpha

Die Anmeldung ist gesperrt. Nur E-Mails auf der Alpha-Zulassungsliste können den Austausch abschließen — ein nicht gelistetes Konto erhält ein 403 email_not_allowed von /v1/auth/exchange zurück und erhält nie eine Session. Zugelassene Konten, die sich angemeldet haben, aber noch nicht freigegeben sind, landen in einem pending-Zustand: Die Konsole leitet sie zu /pending um, und die Control Plane beantwortet gesperrte API-Aufrufe mit 403 alpha_pending, bis ein Operator das Konto freigibt. Siehe Alpha-Zugang, um sich zu bewerben.

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 organisationsbezogene Anmeldeinformationen. Jeder Schlüssel:

Trägt das Format nsk_<random> und wird bei der Erstellung einmal angezeigt.
Wird at-rest gehasht. Wir können den Klartext nach der Erstellung nicht wiederherstellen, also speichern Sie ihn jetzt oder rotieren Sie ihn später.
Gehört zu einer Organisation und handelt mit Ihrer Identität darin.
Kann jederzeit widerrufen werden, ohne andere Schlüssel zu beeinträchtigen.

Verwalten Sie Schlüssel unter Einstellungen → API-Schlüssel in der Konsole. Jede Zeile zeigt den Namen des Schlüssels, die ID, das Erstellungsdatum und wann er zuletzt verwendet wurde. Das Erstellen erfordert einen Namen und enthüllt das Geheimnis einmal; Widerruf und Umbenennung erfolgen inline.

Scopes und Capability

Die Control Plane beschränkt jeden Schlüssel auf zwei Arten:

Scope-Art — org, project oder branch. Ein organisationsbezogener Schlüssel erreicht alles in der Organisation; ein projekt- oder branchbezogener Schlüssel ist auf das/die benannte(n) Projekt(e) oder den Branch beschränkt, und Anfragen für jede andere Ressource erhalten 403 scope_insufficient.
Capability — read oder read_write. Ein read-Schlüssel wird bei jedem mutierenden Aufruf abgelehnt.

Aus der Konsole heute erstellte Schlüssel sind organisationsbezogen mit read_write-Capability — es gibt noch keinen Scope-Auswähler in der UI. Engere Projekt-/Branch-Scopes und die read-Capability sind verfügbar, indem Sie einen scope und eine capability direkt an cps /v1/api-keys/-Endpoint POSTen.

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 Authorize.
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.test.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.