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