現在の導線
一時的な ID ブートストラップ
公開向けの passkey-first サインインはまだ有効化していません。最初の所有者ブートストラップだけは、既存の Ronova private 管理セッションから一時的な高信頼セッションを作れます。
この橋渡しは意図的に狭く保たれています。既存の private 管理セッションが必要で、他ドメイン向けの共有 Cookie は作りません。
中央ディレクトリ
Ronova ID
Ronova の各サイト、各アプリケーション、内部ツールを支える一つの ID 基盤です。
認証はリダイレクトで進み、セッションはアプリ単位に分かれ、権限は全画面へにじまず明示的に保たれます。
中央ディレクトリ
画面を選ぶ
各画面は同じ ID 基盤を共有しますが、答える問いはそれぞれ異なります。
基盤
この基盤が受け持つもの
Ronova ID は飾りのログイン機能ではなく、信頼が始まり、絞られ、後で見直される基盤です。
中央 ID 概要
プロフィールの基準点、所有の筋道、そしてどの Ronova 運用画面が ID を求めているかを一か所で把握します。
公開サイト、実験的アプリケーション、私的コンソールの土台になります。
アプリごとのセッション
各アプリケーションは独自のセッション枠を持つため、一つのツールへのサインインが他の全画面を自動承認することはありません。
高権限作業には短め、低リスク閲覧には穏やかな持続性を想定します。
リダイレクト型認証
認証は、戻り先と理由を明示したリダイレクトで進み、裏側で曖昧に処理されません。
受け渡しの意味が読めるまま残ります。
流れ
リダイレクトの流れ
最初の要求からアプリケーションへ戻るまで、リダイレクトの経路ははっきり見える形に保たれます。
- 01
クライアントが ID を要求する
アプリケーションはクライアント名、求める権限範囲、戻り先を添えて利用者を Ronova ID へ送ります。
- 02
本人が受け渡しを確認する
Ronova ID は、どのクライアントが何を求め、承認後にどこへ戻るのかを本人に示します。
- 03
範囲限定セッションを発行する
発行されるのは求められた範囲だけで、そのセッションはそのクライアントに結びついたままです。
- 04
アプリケーションへ戻す
アプリケーションは許可された ID 文脈で再開し、その一連の要求は後から見直せる形で残ります。
クライアント一覧
アプリケーションとクライアントの一覧
同じ ID 基盤でも、異なる画面に同じ権限を与える必要はありません。
ronova.dev の公開画面
ID の概要、サポート導線、アカウント入口は一つの信頼境界を共有しつつ、ひとつの広すぎるセッションには溶け込みません。
低権限で高い明瞭さ。
gekka-harae.com のアカウント用クライアント
プレイヤー向けサインイン、プロフィール表示、保存データ、アカウント支援は必要な ID だけを求め、管理権限までは引き継ぎません。
利用者単位の権限。
内部運用コンソール
モデレーション、サポート整理、公開運用、監査検索は別々のクライアントとして登録され、より強い統制下に置かれます。
高信頼の運用範囲。
ガバナンス
権限、ロール、監査の考え方
ID は入れるかどうかだけではありません。誰が求め、誰が認め、その後に何が変わったかを示すものでもあります。
権限は明示名で保つ
権限は曖昧な総称ではなく、プロフィール閲覧、サポート文脈の取得、クライアント管理のように読める名前で扱います。
名前のある権限は承認の意味を保ちます。
ロールで作業を束ねる
ロールは繰り返し現れる作業を束ね、運用担当、確認担当、所有者、将来のプロジェクト担当へ分かりやすく割り当てます。
束の名前があると割当てが静かになります。
監査は切り離さない
サインイン、承認、失効、重要変更にはすべて後から確認できる跡が残るべきです。
平時の統制にも障害対応にも役立ちます。