# Étude Web, identité et hébergement des jeux ## Statut Étude non normative pour `0.2.0-0-pre.3`. ## Objectif Permettre un démarrage simple sous une plateforme commune puis une évolution vers des sites et services propres à certains jeux sans casser l'identité joueur. ## Identité canonique Le backend games.sasedev doit posséder un identifiant joueur canonique indépendant des providers externes. Conceptuellement : ```text PlayerId ├─ anonymous device identity ├─ email/password ou passwordless ├─ Google identity ├─ Apple identity ├─ Play Games identity ├─ Steam identity └─ autres providers futurs ``` Un provider externe est une identité liée, pas la clé primaire du joueur. ## Modes d'authentification à prévoir ### Anonymous Cas : - découverte immédiate du jeu ; - première partie sans création de compte ; - fonctionnement offline ou semi-online. Doit permettre si nécessaire : - création d'un profil temporaire ; - migration vers un compte durable ; - conservation de progression lors de l'upgrade. ### Credentials propres Options à étudier : - email + mot de passe ; - username + mot de passe ; - magic link ; - passkey/WebAuthn. Le choix final dépendra des besoins sécurité/UX. ### OAuth / OpenID Connect Providers plausibles : - Google ; - Apple ; - autres comptes sociaux si pertinents. Le backend doit valider les tokens/provider claims puis lier l'identité externe à son `PlayerId`. ### Platform identities Exemples : - Google Play Games ; - Apple Game Center ; - Steam. Ces identités peuvent faciliter sign-in, achievements ou leaderboard mais ne remplacent pas l'identité canonique globale. ## Account linking Cas à prévoir : - anonymous → compte durable ; - Google + Apple sur le même joueur ; - appareil perdu puis récupération ; - changement de provider ; - conflit lorsque deux providers correspondent déjà à deux comptes distincts. Le merge de comptes doit être explicite et sécurisé. ## Sessions Besoins : - access token court ; - refresh/session token ; - révocation ; - liste des devices/sessions éventuellement ; - logout global ou local ; - rotation ; - protection CSRF/cookies pour Web selon architecture ; - stockage sécurisé côté apps natives. Le détail cryptographique sera étudié séparément avant implémentation. ## Portail initial Déploiement initial plausible : ```text games.sasedev.com ``` Responsabilités possibles : - catalogue ; - login/signup ; - compte joueur ; - pages des jeux ; - leaderboards ; - support ; - liens vers stores ; - jeu Web pour les produits compatibles ; - administration séparée. Les premiers jeux peuvent être servis sous : ```text games.sasedev.com/games/snake games.sasedev.com/games/reflex ``` ou équivalent. Le chemin exact n'est pas encore décidé. ## Évolution vers un site propre Un jeu devenu suffisamment important peut avoir : ```text snake.example-game-domain.tld ``` ou un domaine propre. Le déplacement ne doit pas imposer : - nouveau compte joueur ; - nouvelle base d'identité ; - duplication des providers OAuth ; - incompatibilité des leaderboards/progression. Le site propre consomme les services communs via des APIs versionnées. ## Sous-services Découpage logique candidat : ```text www.games.sasedev.com auth.games.sasedev.com api.games.sasedev.com cdn.games.sasedev.com leaderboard.games.sasedev.com realtime.games.sasedev.com admin.games.sasedev.com ``` et, pour un jeu spécifique : ```text www. api. realtime. cdn. ``` Ce sont des frontières logiques possibles, pas une obligation de créer immédiatement tous ces DNS/process. ## Global vs game-specific Services globalement partageables : - auth/identity ; - account/profile ; - entitlement général éventuel ; - catalogue ; - administration centrale ; - common CDN assets éventuels. Services souvent game-specific : - gameplay API ; - matchmaking ; - realtime simulation ; - rulesets ; - game inventory/progression spécialisée ; - events/seasons ; - maps/assets propres au jeu. Certains services, comme leaderboard, peuvent avoir une API générique et une configuration par jeu. ## Multi-tenant logique Le backend commun doit pouvoir distinguer : - `game_id` ; - environment ; - protocol/version ; - player ; - product/platform. Éviter de dupliquer tout le backend par jeu avant qu'une isolation réelle ne soit nécessaire. ## Hébergement et découpage physique Étape initiale plausible : ```text modular monolith ``` avec modules clairement séparés. Évolution possible : ```text auth service API service realtime service leaderboard service game-specific services ``` La séparation physique est motivée par : - charge ; - sécurité ; - cycle de déploiement ; - isolation de panne ; - besoins réseau ; - ownership. Pas par recherche de microservices pour eux-mêmes. ## Web game hosting Un jeu Web/WASM peut être : - servi directement par le portail global ; - servi par son propre site ; - embarqué dans une page Tauri pour certains produits ; - télécharger ses assets depuis un CDN séparé. Le build jeu doit rester indépendant du hostname final. ## CORS / origins / OAuth redirects Le passage d'un domaine global à des domaines propres impose de prévoir : - origins autorisées ; - callback URLs OAuth ; - cookies/domain policy ; - CORS ; - CSP ; - token audience ; - deep links/app links éventuels. Ces points doivent être configurables et non hardcodés dans le gameplay. ## Questions ouvertes - quel provider d'identité implémenter en premier ? - anonymous account server-side dès le début ou seulement local ? - email/password, magic link ou passkey ? - cookies de session pour Web vs bearer tokens pour apps natives ? - comment gérer account merge ? - quel découpage initial entre portail, auth, API et realtime ? - quels services doivent être multi-game dès V1 ? - comment versionner les APIs et protocoles par jeu ?