Répertoire central
Une seule couche d'identité pour les sites, applications et outils internes appartenant à Ronova.
L'authentification reste basée sur la redirection, les sessions restent limitées par application et les permissions restent explicites au lieu de se répandre partout.
Répertoire central
Chaque surface partage la même fondation d'identité, mais chacune répond à une question différente.
Acces direct
Le parcours public passkey-first n'est pas encore actif. Pour l'amorcage initial du proprietaire, Ronova ID peut deriver une session elevee temporaire a partir d'une session admin privee Ronova deja ouverte.
Cette passerelle reste volontairement etroite : elle exige la session admin privee existante et ne cree jamais un cookie partage pour d'autres domaines.
Fondation
Ronova ID est la fondation d'identité, pas un badge de connexion décoratif. C'est là que la confiance commence, se resserre et se vérifie ensuite.
Une seule source de profil, une seule trace de propriété et un seul endroit pour comprendre quelle surface opérée par Ronova demande une identité.
Utile pour les sites publics, les applications expérimentales et les consoles privées.
Chaque application conserve sa propre enveloppe de session afin qu'une connexion sur un outil n'autorise pas silencieusement tous les autres.
Courte durée pour le travail élevé, persistance plus calme pour les vues à faible risque.
L'authentification passe par des redirections explicites avec une destination de retour nommée et une raison enregistrée.
Le transfert reste lisible au lieu de disparaître dans un état en arrière-plan.
Parcours
Le chemin de redirection doit rester explicite depuis la première demande jusqu'au retour de la personne dans l'application.
Une application envoie la personne vers Ronova ID avec son nom de client, la portée demandée et la destination de retour.
Ronova ID montre quel client a demandé, ce qu'il veut et vers quoi la personne sera renvoyée après approbation.
Seule la portée demandée est émise, et la session obtenue reste liée à ce client précis.
L'application reprend avec le contexte d'identité accordé tandis que la chaîne de demande reste visible pour une revue future.
Catalogue des clients
La même couche d'identité peut servir des surfaces très différentes sans prétendre qu'elles ont toutes besoin du même accès.
La vue d'identité, l'orientation du support et les entrées de compte partagent une même frontière de confiance sans se fondre dans une session unique trop large.
Peu de privilèges, beaucoup de clarté.
La connexion côté joueur, la présence de profil, les sauvegardes et l'assistance de compte peuvent demander l'identité nécessaire sans hériter d'un pouvoir administratif.
Accès centré sur l'utilisateur.
La modération, le tri du support, la gouvernance de publication et la recherche d'audit restent des clients distincts avec des contrôles plus forts.
Portée opérationnelle à forte confiance.
Gouvernance
L'identité ne consiste pas seulement à entrer. Elle consiste aussi à prouver qui a demandé, qui a approuvé et ce qui a changé ensuite.
Les permissions restent lisibles plutôt que vagues. Un client doit demander des capacités comme lire le profil, ouvrir un contexte de support ou administrer des clients.
Des permissions nommées rendent l'approbation compréhensible.
Les rôles regroupent le travail récurrent en formes prévisibles pour les opérateurs, les relecteurs, les propriétaires et les futures équipes de projet.
L'attribution devient plus calme quand l'ensemble porte un nom.
Les connexions, approbations, révocations et mutations sensibles doivent toutes laisser une trace pouvant être revue plus tard.
Utile pour les incidents et pour la gouvernance courante.