kisenon

認証

サインイン、組織、API キー、および CLI のループバック OAuth フロー。

Kisenon には認証方法が 2 つあります。

  • Web サインイン — コンソール上の NextAuth を介した Google または GitHub の OAuth。
  • API キー — 任意の HTTP クライアント(keon を含む)が Bearer 資格情報として提示できる nsk_… トークン。

同じキーで CLI、CI、および単発の curl 呼び出しを動かせます。

Web サインイン

kisenon.com を開き、Sign in をクリックします。Google または GitHub を選びます。NextAuth が OAuth のやり取りを処理し、その後 POST /v1/auth/exchange を介してプロバイダの id トークンをコントロールプレーン の JWT と交換します。この cp 署名済み JWT が、以降のすべてのコンソールリクエスト が携える資格情報です。

JWT は短命で、発行からおよそ 15 分で失効します。アクティブな間は、NextAuth が現在 の JWT を POST /v1/auth/refresh に再提示することでバックグラウンドで更新し、新 しいものを発行します。更新用の資格情報は JWT そのもので、サインインから 12 時間の ウィンドウ内で有効です。そのウィンドウが過ぎると、次のリクエストでサインインへ リダイレクトされます。

アクセス

Google または GitHub でサインインします。オープンサインアップが有効な場合、新しい アカウントはすぐに利用できます。初回の交換であなたのユーザーと個人組織が作成され、 そのままコンソールに入ります。

オンボーディングの間はアクセスを制限できます — オペレーターが環境ごとに切り替えら れるキルスイッチです。これが有効な場合、サインイン済みだがまだ有効化されていない アカウントは pending 状態に入ります。コンソールはそれを /pending へリダイレ クトし、アカウントが有効化されるまで、コントロールプレーンはゲート対象の API 呼び 出しに 403 alpha_pending で応答します。設定されたサインイン許可リストによって、 セッションが発行される前に、リストにないアカウントを 403 email_not_allowed で 拒否することもできます。

組織とロール

アイデンティティは組織を起点とします。すべてのセッションは アクティブな組織 とそこでのあなたの ロール(例えば ownermember)を携えます。cp の JWT は両方をエンコードし、コントロールプレーンは更新のたびにあなたのロールを再読み取り します。個人サインアップには個人組織が自動的に付与され、招待されたユーザーは初回 サインイン時にチーム組織に入ります。

複数の組織に所属している場合、コンソール(サインイン後レイアウトの上部)の 組織スイッチャー がロールバッジ付きでそれらを一覧表示します。1 つを選ぶと /api/auth/switch-org に POST され、それが cp の /v1/auth/switch-org にプロキシ して、新しい組織にスコープされた新しい JWT をセッションに差し込みます。切り替え後 のすべてのコンソールリクエストは、選択した組織内で動作します。

組織とロールの仕組みについては 組織 を、チームメンバーの 追加については 招待 を参照してください。

API キー

API キーは nsk_ 接頭辞付きの資格情報です。各キーは次のとおりです。

  • nsk_<random> 形式を持ち、作成時に 一度だけ 表示されます — 保存時に ハッシュ化されるため、後から平文を復元することはできません。今すぐ保存するか、 ローテーションしてください。
  • そのスコープ内であなたのアイデンティティとして動作します。
  • 他のキーに影響を与えることなく、いつでも失効させられます。

コンソールからのキーの発行

キーは Settings → API keys で発行します。各行にはキーの名前、 id、作成日、最終使用日時が表示されます。作成フォームには 4 つのフィールドがありま す。

  • Name — ラベル。最大 64 文字。
  • Capability — 下記参照。
  • Scope — 下記参照。
  • Expires (days) — 期限切れにならないキーの場合は空欄にします。

送信すると、シークレットが 一度だけ 表示されます。ダイアログを閉じる前にコピー してください。

Capability はキーが何をできるかを選びます。

  • read_write(デフォルト)— 完全な読み取りと書き込み。
  • read — 読み取り専用。変更を伴う呼び出しでは拒否されます。
  • agent — サンドボックスを駆動できますが、書き込み可能な main の資格情報を 取得することは できません。この capability を AI エージェントに渡すことで、 本番の main に一切触れることなくブランチに対して動作させられます。 Agent-Safe Change Control を参照してください。

Scope はキーが到達できる範囲を選びます。

  • Organization(デフォルト)— アクティブな組織内のすべて。
  • 特定のプロジェクト — そのプロジェクトに制限されます。それ以外のリソースへの リクエストは 403 scope_insufficient を受け取ります。(ブランチスコープも API 経由でサポートされます。)

キーの 作成 にはサインイン済みのブラウザセッションが必要です — nsk_ キーで 別のキーを発行することはできません。キーは 自身を失効 させられますが、nsk_ ベアラーは自己失効のみが可能で、他のキーを削除することはできません。

API 経由

同じ操作は cp の /v1/api-keys/ エンドポイントで利用できます。namescopecapability を POST して作成すると、レスポンスは平文のシークレットを一度だけ携え ます。

IP 許可リスト

各プロジェクトは CIDR の ネットワーク許可リスト を持てます。リストが設定される と、リストにある CIDR から発信された接続のみがプロジェクトのエンドポイントに到達し ます。強制は wake パスにも及ぶので、リストにないクライアントはサスペンド中のエンド ポイントを起こすこともできません。 の許可リストは IP 制限なしを意味し、すべ てのソースが許可されます。

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

または API 経由で。

  • GET /v1/projects/{projectId}/ip-allow — 現在のルールを一覧します。
  • POST /v1/projects/{projectId}/ip-allow — ルールを追加します。ボディは {cidr, label, ttl_seconds?} です。ttl_seconds は省略可能で、ルールを自動失効 させます。不正な CIDR は 422 を返します。
  • DELETE /v1/projects/{projectId}/ip-allow/{cidr} — ルールを 1 つ削除します。
  • DELETE /v1/projects/{projectId}/ip-allow — リスト全体をリセットします。

強制はプロキシで行われ、プロキシはおよそ 30 秒ごとにビューを更新するため、変更は 数秒以内に伝播します。

CLI のループバック OAuth

keon login では API キーの貼り付けを求められません。代わりにループバック OAuth フローを実行します。

  1. CLI がランダムな高位ポートでローカル HTTP リスナーを起動します。
  2. 使い捨ての state トークンとループバックのリダイレクト URL とともに、ブラウザを https://kisenon.com/cli/authorize?... へ開きます。
  3. あなたがサインイン(または既にサインイン済み)し、Authorize をクリックします。
  4. コンソールが短命のコードとともにループバック URL へリダイレクトします。
  5. CLI が POST /v1/cli/exchange でそのコードを、新たに発行された API キーと交換 します。
  6. キーはモード 0600~/.config/keon/credentials.json に永続化されます。

フローの後、keon whoami でキーが結び付いていることを確認できます。

keon login
keon whoami

CLI は OAuth コード、state、いかなるプロバイダ側トークンも保存しません。保存するの は結果として得られた API キーのみです。そのキーはいつでもコンソールからローテーション または失効させられます。

ログアウト

keon logout はサーバー上のローカル API キーを失効させ、資格情報ファイルを削除しま す。ログアウト後、同じ keon login フローで新しいキーが発行されます — 古い資格情報 を再有効化することはできません。

keon logout

コンソールのサインアウトはブラウザセッションをクリアし、ランディングページへリダイ レクトします。CLI で発行した API キーは失効させません。それらを個別に失効させるには Settings → API keys を使ってください。

任意のクライアントからの Bearer 認証

HTTP を話せるクライアントなら何でもコントロールプレーンに到達できます。

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

ベアラートークンは API キー(nsk_…)か、/v1/auth/exchange で発行された cp 署名 済み JWT のいずれかです。組織スコープのエンドポイントでは両者は等価です。

関連

  • 組織 — 組織、ロール、切り替え。
  • 招待 — 組織へのチームメンバーの追加。
  • CLI — インストール、ログイン、よく使うコマンド。
  • セキュリティ — 開示ポリシー。
  • FAQ — よくある質問への簡潔な回答。