6.0 KiB
É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 :
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 :
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 :
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 :
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 :
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 :
www.<game-domain>
api.<game-domain>
realtime.<game-domain>
cdn.<game-domain>
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 :
modular monolith
avec modules clairement séparés.
Évolution possible :
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 ?