即時入口
暫時身分啟動橋接
公開的 passkey-first 登入流程尚未啟用。若要做第一次擁有者啟動，Ronova ID 可以從既有的 Ronova private 管理工作階段導出一個暫時的高信任工作階段。
這條橋接路徑刻意保持狹窄：它要求既有的 private 管理工作階段，而且不會替其他網域建立共享 Cookie。
中央目錄
選擇介面
每個介面共享同一套身分基礎，但它們回答的問題並不一樣。
基礎
這個基礎涵蓋什麼
Ronova ID 不是裝飾性的登入徽章，而是信任從哪裡開始、在哪裡收斂、之後如何回頭檢查的基礎。
中央身分總覽
用一個地方掌握個人資料來源、所有權脈絡，以及哪個 Ronova 介面正在要求身分。
可用於公開網站、實驗性應用程式與私有主控台。
應用程式分域工作階段
每個應用程式保有自己的工作階段外殼，因此登入其中一個工具時，不會默默授權所有其他工具。
高權限工作可更短命，低風險瀏覽可更平穩。
導轉式認證
認證透過明確導轉完成，帶著回返目標與請求理由，不在背景狀態裡悄悄發生。
交接過程保持可讀。
流程
導轉旅程
從第一次請求到回到應用程式，整條導轉路徑都應該維持清楚可見。
- 01
用戶端請求身分
應用程式把用戶端名稱、需要的權限範圍與回返目的地一起送往 Ronova ID。
- 02
本人確認交接內容
Ronova ID 會說明是哪個用戶端發起請求、想要什麼，以及核准後會回到哪裡。
- 03
建立範圍限定的工作階段
系統只發出被要求的範圍，而且產生的工作階段會綁定在那個用戶端上。
- 04
把本人送回應用程式
應用程式帶著已授權的身分脈絡繼續運作，而整條請求鏈保留下來供後續檢查。
用戶端目錄
應用程式與用戶端目錄
同一套身分基礎可以服務非常不同的介面，而不必假裝它們都需要同一種存取。
ronova.dev 公開介面
身分總覽、支援導向與帳戶入口共用同一條信任邊界，但不會混成一個過於寬鬆的工作階段。
低權限、高清晰度。
gekka-harae.com 帳戶用戶端
玩家登入、個人頁面存在感、存檔與帳戶支援可以只索取所需身分，不會順手繼承管理權限。
以使用者為中心的存取。
內部營運主控台
審核、支援分流、發布治理與稽核查詢維持為不同用戶端，並接受更嚴格的控管。
高信任的營運範圍。
治理
權限、角色與稽核觀念
身分不只是能不能進去，也是在說明誰提出要求、誰核准，以及之後發生了什麼變化。
權限保持明確
權限應該保持可讀，不要用籠統詞。用戶端要的是讀取個人資料、開啟支援上下文、管理其他用戶端之類的具名能力。
具名權限讓核准更容易理解。
角色把工作打包
角色把重複出現的工作打包成可預測的責任形狀，方便營運人員、審查者、擁有者與未來的專案團隊使用。
打包後，指派就不再混亂。
稽核不脫鉤
登入、核准、撤銷與敏感變更都應留下之後能回看的軌跡。
平時治理與事件追查都用得到。