認証
サインイン、組織、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 時間の
ウィンドウ内で有効です。そのウィンドウが過ぎると、次のリクエストでサインインへ
リダイレクトされます。
アルファ期間中のアクセス
サインインはゲートされています。アルファの許可リストに載っているメールアドレス
のみが交換を完了できます。リストにないアカウントは /v1/auth/exchange から
403 email_not_allowed を受け取り、セッションを得られません。許可リストに載って
いてサインイン済みだが、まだ承認されていないアカウントは pending 状態に入りま
す。コンソールはそれらを /pending へリダイレクトし、オペレーターがアカウントを
承認するまで、コントロールプレーンはゲート対象の API 呼び出しに 403 alpha_pending
で応答します。応募については アルファアクセス を参照してください。
組織とロール
アイデンティティは組織を起点とします。すべてのセッションは アクティブな組織
とそこでのあなたの ロール（例えば owner や member）を携えます。cp の JWT
は両方をエンコードし、コントロールプレーンは更新のたびにあなたのロールを再読み取り
します。個人サインアップには個人組織が自動的に付与され、招待されたユーザーは初回
サインイン時にチーム組織に入ります。
複数の組織に所属している場合、コンソール（サインイン後レイアウトの上部）の
組織スイッチャー がロールバッジ付きでそれらを一覧表示します。1 つを選ぶと
/api/auth/switch-org に POST され、それが cp の /v1/auth/switch-org にプロキシ
して、新しい組織にスコープされた新しい JWT をセッションに差し込みます。切り替え後
のすべてのコンソールリクエストは、選択した組織内で動作します。
組織とロールの仕組みについては 組織 を、チームメンバーの 追加については 招待 を参照してください。
API キー
API キーは組織にスコープされた資格情報です。各キーは次のとおりです。
- 形式は
nsk_<random>で、作成時に一度だけ表示されます。 - 保存時にハッシュ化されます。作成後に平文を復元することはできないため、今すぐ 保存するか、後でローテーションしてください。
- 1 つの組織に属し、その中であなたのアイデンティティとして動作します。
- 他のキーに影響を与えることなく、いつでも失効させられます。
キーの管理はコンソールの Settings → API keys で行います。各 行にはキーの名前、id、作成日、最終使用日時が表示されます。作成では名前を取り、 シークレットを一度だけ表示します。失効とリネームはインラインで行えます。
スコープとケイパビリティ
コントロールプレーンは各キーを 2 つの観点でスコープします。
- スコープの種類 —
org、project、またはbranch。組織スコープのキーは組織 内のすべてに到達します。プロジェクトまたはブランチスコープのキーは、指定された プロジェクトまたはブランチに制限され、それ以外のリソースへのリクエストは403 scope_insufficientを受け取ります。 - ケイパビリティ —
readまたはread_write。readキーは、変更を伴う呼び 出しでは拒否されます。
現在コンソールから作成されるキーは、read_write ケイパビリティを持つ
組織スコープ です。UI にはまだスコープ選択がありません。より狭い
プロジェクト／ブランチスコープと read ケイパビリティは、cp の /v1/api-keys/
エンドポイントに scope と capability を直接 POST することで利用できます。
CLI のループバック OAuth
keon login では API キーの貼り付けを求められません。代わりにループバック OAuth
フローを実行します。
- CLI がランダムな高位ポートでローカル HTTP リスナーを起動します。
- 使い捨ての state トークンとループバックのリダイレクト URL とともに、ブラウザを
https://kisenon.com/cli/authorize?...へ開きます。 - あなたがサインイン（または既にサインイン済み）し、Authorize をクリックします。
- コンソールが短命のコードとともにループバック URL へリダイレクトします。
- CLI が
POST /v1/cli/exchangeでそのコードを、新たに発行された API キーと交換 します。 - キーはモード
0600で~/.config/keon/credentials.jsonに永続化されます。
フローの後、keon whoami でキーが結び付いていることを確認できます。
keon login
keon whoamiCLI は 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.test.kisenon.com/v1/projectsベアラートークンは API キー（nsk_…）か、/v1/auth/exchange で発行された cp 署名
済み JWT のいずれかです。組織スコープのエンドポイントでは両者は等価です。