Central directory
One identity layer for Ronova-owned websites, applications, and internal tools.
Authentication stays redirect-based, sessions stay app-scoped, and permissions stay explicit instead of bleeding across every surface.
Central directory
Each surface shares the same identity foundation, but each one answers a different question.
Live access
Ronova ID now signs in with user-verified passkeys. The temporary bootstrap remains only so an existing private admin session can enroll the first owner passkey.
Ronova ID is issued for Ronova-operated projects by invitation, migration, or a reviewed request through project support/contact. There is no public self-service registration form here.
Ronova subdomains can share the same-site ID session; other registered clients still use redirect codes.
Foundation
Ronova ID is the identity foundation, not a decorative login badge. It defines where trust begins, where it narrows, and how it is reviewed later.
One profile source, one ownership trail, and one place to understand which Ronova-operated surface is asking for identity.
Useful for public sites, experimental apps, and private consoles.
Each application keeps its own session envelope so signing into one tool does not silently authorize every other tool.
Short-lived for elevated work, calmer persistence for low-risk views.
Authentication happens through deliberate redirects with a named return target and a recorded reason for the request.
The handoff stays readable instead of disappearing into background state.
Flow
The redirect path is meant to stay explicit from the first request to the app receiving the user back.
An app sends the visitor to Ronova ID with its client name, requested scope, and return destination.
Ronova ID shows which client asked, what it wants, and what the user will be sent back to after approval.
Only the requested scope is issued, and the resulting session is bound to that specific client.
The application resumes with the granted identity context while the request chain stays visible for later review.
Client catalog
The same identity layer can serve very different surfaces without pretending they all need the same access.
Identity overview, support routing, and account entry points share one trust boundary without collapsing into a single broad session.
Low privilege, high clarity.
Player-facing sign-in, profile presence, saves, and account support can ask for the identity they need without inheriting admin power.
User-scoped access.
Moderation, support triage, release governance, and audit search stay registered as distinct clients with stronger controls.
High-trust operational scope.
Governance
Identity is not only about getting in. It is also about proving who asked, who approved, and what changed after access was granted.
Scopes stay readable instead of vague. A client should ask for capabilities such as reading profile data, opening support context, or administering clients.
Named permissions keep approvals legible.
Roles collect repeatable work into predictable shapes for operators, reviewers, owners, and future project-specific teams.
Assignment stays calm when the bundle has a name.
Sign-ins, grants, revocations, and sensitive mutations should all leave a trail that can be inspected later.
Useful for incident review and routine governance.